qemu-devel.nongnu.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).