All of lore.kernel.org
 help / color / mirror / Atom feed
From: "André Braga" <meianoite@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Stupid (probably) idea wrt dyngen & gcc 3.4 & 4.0
Date: Sun, 8 May 2005 21:25:42 -0300	[thread overview]
Message-ID: <2ad73a050508172549135036@mail.gmail.com> (raw)
In-Reply-To: <200505090202.00547.sk@z.pl>

Alternatively, 

volatile 
  inc ax
  dec ax
  inc ax
  dec ax

which is the same size as 4 nops (on x86 assembly), has a net result
of doing nothing (caveat interrupts/preemption), and is *absolutely
illogical* to find in any machine-generated code...

There must be some way to generate similar code on other supported
platforms (I mean: code that's extremely unlikely to be generated by a
machine but could be used as a sentinel code sequence to dyngen), but
feasibility considerations apart, I don't really think this is the
most elegant solution...


2005/5/8, Sebastian Kaliszewski <sk@z.pl>:
> 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" );
> 
> or
> 
> #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
> trivial.
> 
> What do you think?
> 
> rgds
> Sebastian Kaliszewski

  reply	other threads:[~2005-05-09  0:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-09  0:02 [Qemu-devel] Stupid (probably) idea wrt dyngen & gcc 3.4 & 4.0 Sebastian Kaliszewski
2005-05-09  0:25 ` André Braga [this message]
2005-05-09  0:40 ` Paul Brook
2005-05-09  1:55   ` Sebastian Kaliszewski
2005-05-09  2:33     ` Paul Brook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2ad73a050508172549135036@mail.gmail.com \
    --to=meianoite@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.