Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Gary Benson <gbenson@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] Allow setting breakpoints on inline functions (PR 10738)
Date: Fri, 02 Dec 2011 13:48:00 -0000	[thread overview]
Message-ID: <20111202134817.GB2862@redhat.com> (raw)
In-Reply-To: <m3d3c9ilpc.fsf@fleche.redhat.com>

Tom Tromey wrote:
> >>>>> "Gary" == Gary Benson <gbenson@redhat.com> writes:
> 
> Gary> This patch, which applies on top of Tom's ambiguous linespec work,
> Gary> allows you to set breakpoints on inlined functions.  Although it
> Gary> can't be committed until Tom's stuff goes in, I'm posting it for
> Gary> feedback now.
> 
> I noticed that the manual node "Inline Functions" says:
> 
>        There are some ways that GDB does not pretend that inlined function
>     calls are the same as normal calls:
> 
>        * You cannot set breakpoints on inlined functions.  GDB
>          either reports that there is no symbol with that name, or
>          else sets the breakpoint only on non-inlined copies of the
>          function.  This limitation will be removed in a future
>          version of GDB; until then, set a breakpoint by line number
>          on the first line of the inlined function instead.
>     [...]
> 
> I think this needs a small update.

I removed that entire bullet point.

> Also I think this feature deserves a NEWS entry.

I added "* GDB can now set breakpoints on inlined functions." on the
branch.

> I checked it out and played with it a little.  I found one little
> bug.  Using the inline-break test case from the patch:
> 
> (gdb) p &func1
> $1 = (int (*)(int)) 0x4003d8 <main+8>
> 
> That is, it chooses the location of the inline function as the
> address of the function when evaluating an expression.  I think
> this is wrong.  Instead, it should ignore inline instances here,
> returning the address of the out-of-line instance.  And, if there
> is no out-of-line (as in this case), it should error.
> 
> I think one possible way to do this would be to put a flag on
> symbols, marking inline instances, and then have ordinary symbol
> lookup ignore such symbols.  I am not sure how hard this would be.
> There might also be other approaches.

There already is such a flag: SYMBOL_INLINED (sym).  I've pushed
a fix to the branch to make lookup_block_symbol skip over inlined
symbols.  It works as you ask with no regressions.

I won't make a new patch yet as I need to look at some of Jan's
suggestions.

Thanks,
Gary

-- 
http://gbenson.net/


  reply	other threads:[~2011-12-02 13:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29 15:02 Gary Benson
2011-11-30 17:07 ` Tom Tromey
2011-12-02 13:48   ` Gary Benson [this message]
2011-11-30 20:19 ` Jan Kratochvil
2011-12-01 13:41   ` Gary Benson
2011-12-01 18:53     ` Jan Kratochvil

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=20111202134817.GB2862@redhat.com \
    --to=gbenson@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --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