[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Stupid (probably) idea wrt dyngen & gcc 3.4 & 4.0

From: Sebastian Kaliszewski
Subject: [Qemu-devel] Stupid (probably) idea wrt dyngen & gcc 3.4 & 4.0
Date: Mon, 9 May 2005 02:02:00 +0200
User-agent: KMail/1.4.3


As I understand the problem with dyngen & GCC 3.4 and newer is that even 
when using the following marcro (line 158 of dynget-exec.h) in op_* 

#define FORCE_RET() asm volatile ("");

GCC still puts multiple exit points of a function.

But did anyone try the following one:

#define FORCE_RET() asm volatile ("" : : : "memory" );

This tells GCC that that asm block clobbers arbitrary memory. If it doesnt 
help, then maybe putting few instructions will help (increasing the weight 
of the code thus convincing optimiser not to multiplicate the asm block)?

#define FORCE_RET() asm volatile ("nop; nop; nop; nop" : : : "memory" );


#define FORCE_RET() asm volatile ("ret; ret; ret; ret" : : : "memory" );

Then if the above fails, then simply search the binary code for such block 
of fout instructions (in case of nops it'd be 0x90909090, in case of ret's 
-- don't remember). It's rather impossible, that such immediate value would 
apear inside op_* code, so the only real possibility is FORCE_RET() 
occurence (Ther is also slim possibility that such code would be an align 
fill block -- but AFAIR gcc is instructed ther not to align code and AFAIR 
gcc would use block of 4 one byte nops -- it will use longer nops in such 
cases). So then replacing such nops with jumps to end inside blocks is 

What do you think?

Sebastian Kaliszewski
"Never undersetimate the power of human stupidity" -- from notebooks of L.L.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]