Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA] Allow setting breakpoints on inline functions (PR 10738)
Date: Wed, 30 Nov 2011 17:07:00 -0000	[thread overview]
Message-ID: <m3d3c9ilpc.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20111129150200.GB3425@redhat.com> (Gary Benson's message of	"Tue, 29 Nov 2011 15:02:00 +0000")

>>>>> "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.

This is super.  Thanks.

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.

Also I think this feature deserves a NEWS entry.

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.

Tom


  reply	other threads:[~2011-11-30 17:07 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 [this message]
2011-12-02 13:48   ` Gary Benson
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=m3d3c9ilpc.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /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