Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Stan Shebs <stan@codesourcery.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: Stan Shebs <stan@codesourcery.com>, Doug Evans <dje@google.com>,
	 gdb-patches@sourceware.org, Eli Zaretskii <eliz@gnu.org>,
	 tromey@redhat.com
Subject: Re: [NEWS/RFA] Re: [gdbserver] x86 agent expression bytecode compiler (speed up conditional tracepoints)
Date: Wed, 16 Jun 2010 19:31:00 -0000	[thread overview]
Message-ID: <4C19265B.7090502@codesourcery.com> (raw)
In-Reply-To: <201006162016.18181.pedro@codesourcery.com>

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 <pedro@codesourcery.com> 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:                                                   \
>>>     ; }
>>>
>>>   
>>>       
>>     
>
>
>   


  parent reply	other threads:[~2010-06-16 19:31 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-07 16:00 Pedro Alves
2010-06-07 16:04 ` Michael Snyder
2010-06-07 16:35   ` Joel Brobecker
2010-06-10 17:28 ` Tom Tromey
2010-06-10 17:36   ` Pedro Alves
2010-06-10 18:43     ` Tom Tromey
2010-06-14 11:15       ` [NEWS/RFA] " Pedro Alves
2010-06-14 17:29         ` Eli Zaretskii
2010-06-14 22:19           ` Pedro Alves
2010-06-16 18:57             ` Doug Evans
2010-06-16 19:13               ` Stan Shebs
2010-06-16 19:16                 ` Pedro Alves
2010-06-16 19:21                   ` Doug Evans
2010-06-16 23:58                     ` Ian Lance Taylor
2010-06-20 22:27                       ` Pedro Alves
2010-06-16 19:31                   ` Stan Shebs [this message]
2010-06-17 18:03                     ` Michael Snyder
2010-06-19 16:13                       ` Hui Zhu
2010-06-19 16:16                         ` Doug Evans
2010-06-19 17:13                           ` Hui Zhu
2010-06-19 17:26                             ` Doug Evans
2010-06-20  9:30                               ` [RFA-new version][gdbserver] " Pierre Muller
     [not found]                               ` <-3945058798826177264@unknownmsgid>
2010-06-20 15:30                                 ` Doug Evans
2010-06-20 17:02                                   ` Pierre Muller
     [not found]                                   ` <-1673004315710326113@unknownmsgid>
2010-06-20 17:11                                     ` Doug Evans
2010-06-20 18:41                                   ` Tom Tromey
2010-06-20 20:36                                     ` Pierre Muller
2010-06-20 21:07                                       ` Pierre Muller
2010-06-21  1:47                                         ` Tom Tromey
2010-06-21  6:31                                           ` Pierre Muller
2010-06-20 18:31                         ` [NEWS/RFA] Re: [gdbserver] " Tom Tromey

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=4C19265B.7090502@codesourcery.com \
    --to=stan@codesourcery.com \
    --cc=dje@google.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    --cc=tromey@redhat.com \
    /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