From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26138 invoked by alias); 17 Jun 2010 18:03:24 -0000 Received: (qmail 25936 invoked by uid 22791); 17 Jun 2010 18:03:23 -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 smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Jun 2010 18:03:18 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 34F7613014; Thu, 17 Jun 2010 11:03:15 -0700 (PDT) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by mailhost3.vmware.com (Postfix) with ESMTP id 29BDBCD915; Thu, 17 Jun 2010 11:03:15 -0700 (PDT) Message-ID: <4C1A6362.3020306@vmware.com> Date: Thu, 17 Jun 2010 18:03:00 -0000 From: Michael Snyder User-Agent: Thunderbird 2.0.0.22 (X11/20090609) MIME-Version: 1.0 To: Stan Shebs CC: Pedro Alves , 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> <4C19265B.7090502@codesourcery.com> In-Reply-To: <4C19265B.7090502@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00383.txt.bz2 Stan Shebs wrote: > 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. Hurrr. Code that depends on such deep knowledge of the compiler's behavior is wrong code, IMO.