From: Sebastian Kaliszewski <sk@z.pl>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Stupid (probably) idea wrt dyngen & gcc 3.4 & 4.0
Date: Mon, 9 May 2005 02:02:00 +0200 [thread overview]
Message-ID: <200505090202.00547.sk@z.pl> (raw)
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
--
"Never undersetimate the power of human stupidity" -- from notebooks of L.L.
next reply other threads:[~2005-05-09 0:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-09 0:02 Sebastian Kaliszewski [this message]
2005-05-09 0:25 ` [Qemu-devel] Stupid (probably) idea wrt dyngen & gcc 3.4 & 4.0 André Braga
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=200505090202.00547.sk@z.pl \
--to=sk@z.pl \
--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).