From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DUwDc-0004nE-RF for qemu-devel@nongnu.org; Sun, 08 May 2005 20:33:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DUwDW-0004hG-Bt for qemu-devel@nongnu.org; Sun, 08 May 2005 20:33:51 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DUwDS-0004ej-GF for qemu-devel@nongnu.org; Sun, 08 May 2005 20:33:46 -0400 Received: from [64.233.162.202] (helo=zproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DUwBV-0001WF-9l for qemu-devel@nongnu.org; Sun, 08 May 2005 20:31:45 -0400 Received: by zproxy.gmail.com with SMTP id 8so1233180nzo for ; Sun, 08 May 2005 17:25:42 -0700 (PDT) Message-ID: <2ad73a050508172549135036@mail.gmail.com> Date: Sun, 8 May 2005 21:25:42 -0300 From: =?ISO-8859-1?Q?Andr=E9_Braga?= Subject: Re: [Qemu-devel] Stupid (probably) idea wrt dyngen & gcc 3.4 & 4.0 In-Reply-To: <200505090202.00547.sk@z.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200505090202.00547.sk@z.pl> Reply-To: =?ISO-8859-1?Q?Andr=E9_Braga?= , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Alternatively,=20 volatile=20 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 : > Hello! >=20 > 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 >=20 > #define FORCE_RET() asm volatile (""); >=20 > GCC still puts multiple exit points of a function. >=20 > But did anyone try the following one: >=20 > #define FORCE_RET() asm volatile ("" : : : "memory" ); >=20 > This tells GCC that that asm block clobbers arbitrary memory. If it doesn= t > help, then maybe putting few instructions will help (increasing the weigh= t > of the code thus convincing optimiser not to multiplicate the asm block)? >=20 > #define FORCE_RET() asm volatile ("nop; nop; nop; nop" : : : "memory" ); >=20 > or >=20 > #define FORCE_RET() asm volatile ("ret; ret; ret; ret" : : : "memory" ); >=20 > Then if the above fails, then simply search the binary code for such bloc= k > 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 wou= ld > 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 AFAI= R > 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. >=20 > What do you think? >=20 > rgds > Sebastian Kaliszewski