From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18927 invoked by alias); 16 Jun 2010 19:16:32 -0000 Received: (qmail 18917 invoked by uid 22791); 16 Jun 2010 19:16:30 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Jun 2010 19:16:25 +0000 Received: (qmail 15515 invoked from network); 16 Jun 2010 19:16:23 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Jun 2010 19:16:23 -0000 From: Pedro Alves To: Stan Shebs Subject: Re: [NEWS/RFA] Re: [gdbserver] x86 agent expression bytecode compiler (speed up conditional tracepoints) Date: Wed, 16 Jun 2010 19:16:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-22-generic; KDE/4.4.2; x86_64; ; ) Cc: Doug Evans , gdb-patches@sourceware.org, Eli Zaretskii , tromey@redhat.com References: <201006071700.28706.pedro@codesourcery.com> <4C19222C.2000208@codesourcery.com> In-Reply-To: <4C19222C.2000208@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006162016.18181.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-06/txt/msg00373.txt.bz2 On Wednesday 16 June 2010 20:12:44, Stan Shebs wrote: > Doug Evans wrote: > > On Mon, Jun 14, 2010 at 3:19 PM, Pedro Alves wrote: > > > >> Thanks. I've checked the whole thing in. > >> > > > > I'm getting build failures that go away when compiling linux-x86-low.c with -g. > > > > gcc is optimizing out the skipped over stuff I believe. > > > > Hmm, this particular trickery was my idea, but it always seemed > vulnerable to ever-smarter optimization. Does anybody have any better > strategy? Declaring the asm volatile didn't work, because the compiler > was whacking everything around it. > > The other approach is to build up instructions from bitfields, which is > reliable but needs a lot of setup and helper routines. Quick thought: can we stick a couple of __attribute__((used))'s in the macro, so the compiler doesn optimized things away, thinking they're unused (given the uses are behind asm)? > > Stan > > > > /* Our general strategy for emitting code is to avoid specifying raw > > bytes whenever possible, and instead copy a block of inline asm > > that is embedded in the function. This is a little messy, because > > we need to keep the compiler from discarding what looks like dead > > code, plus suppress various warnings. */ > > > > #define EMIT_ASM(NAME,INSNS) \ > > { extern unsigned char start_ ## NAME, end_ ## NAME; \ > > add_insns (&start_ ## NAME, &end_ ## NAME - &start_ ## NAME); \ > > if (always_true ()) \ > > goto skipover ## NAME; \ > > __asm__ ("start_" #NAME ":\n\t" INSNS "\n\tend_" #NAME ":\n\t"); \ > > skipover ## NAME: \ > > ; } > > > > > > -- Pedro Alves