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

[Paul Brook <paul@nowt.org>]

On Monday 09 May 2005 01:02, Sebastian Kaliszewski wrote:
> Hello!
>
> 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_*
> functions
>
> #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" );


No. The main problem with gcc3.4 was that we weren't using FORCE_RET 
everywhere that we should. This has mostly been fixed now.


The problem with gcc4 is that -fno-reorder-blocks no longer does what we want. 
There is no way to force gcc to put the the end of the function at the end.

As far as gcc is concerned there's nothing special about the "end" of the 
function. gcc will turn

  if (unlikely)
    something();
  rest_of_function();
  FORCE_RET();
  return;

into

  if (unlikely) goto unlikely_code;
return_from_unlikely:
  rest_of_function();
  return;

unlikely_code:
  something();
  goto return_from_unlikely;

making rest_of_function bigger won't help.

> Then if the above fails, then simply search the binary code for such block 
> of fout instructions

This won't work either. the FORCE_RET is before the function epilogue. ie. you 
might have:

op_foo:
    push %ebx
    # function code
    # the assembly from FORCE_RET
    pop %ebx
    ret

If you amputate this at the FORCE_RET you end up with a stack overflow.

I've got a solution for x86/x86-64 that's 95% complete, using the method I 
suggested in a previous email. I hope to be submitting a patch shortly.
I expect most other hosts (particularly the RISC based ones) to be much 
simpler to fix.

Paul