From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24959 invoked by alias); 16 Jun 2010 19:31:00 -0000 Received: (qmail 24946 invoked by uid 22791); 16 Jun 2010 19:30:57 -0000 X-SWARE-Spam-Status: No, hits=-2.0 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:30:44 +0000 Received: (qmail 24590 invoked from network); 16 Jun 2010 19:30:41 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Jun 2010 19:30:41 -0000 Message-ID: <4C19265B.7090502@codesourcery.com> Date: Wed, 16 Jun 2010 19:31:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pedro Alves CC: Stan Shebs , Doug Evans , gdb-patches@sourceware.org, Eli Zaretskii , tromey@redhat.com Subject: Re: [NEWS/RFA] Re: [gdbserver] x86 agent expression bytecode compiler (speed up conditional tracepoints) References: <201006071700.28706.pedro@codesourcery.com> <4C19222C.2000208@codesourcery.com> <201006162016.18181.pedro@codesourcery.com> In-Reply-To: <201006162016.18181.pedro@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00375.txt.bz2 Pedro Alves wrote: > 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)? > The compiler is discarding the code with the definitions of the labels, because it's thinking they are maybe somewhere else in the program (the error is at link time). Moving the labels into C code would fix that I think, but then it's hard to guarantee that the compiler won't sneak in a bit of code between label and asm sequence. Stan >> 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: \ >>> ; } >>> >>> >>> >> > > >