Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [FYI] Inlining support, rough patch
Date: Fri, 25 Jul 2008 14:26:00 -0000	[thread overview]
Message-ID: <20080725142551.GA15973@caradoc.them.org> (raw)
In-Reply-To: <umyk6ysql.fsf@gnu.org>

Thanks for looking at this.

On Fri, Jul 25, 2008 at 04:54:10PM +0300, Eli Zaretskii wrote:
> > +There are some ways that @value{GDBN} cannot pretend that inlined
> > +function calls are the same as normal calls:
> > +
> > +@itemize @bullet
> > +@item
> > +You cannot set breakpoints on inlined functions.  @value{GDBN}
> > +either reports that there is no symbol with that name, or else sets the
> > +breakpoint on the non-inlined copy of the function.
> > +
> > +@item
> > +Setting breakpoints at the call site of an inlined function may not
> > +work, because the call site does not contain any code.  @value{GDBN}
> > +may incorrectly move the breakpoint to the next line of the enclosing
> > +function, after the call.
> > +
> > +@item
> > +@value{GDBN} cannot locate the return value of inlined calls after
> > +using the @code{finish} command.
> > +
> > +@end itemize
> 
> This is IMO too negative: you state several problems and never hint on
> how to work around them.  Please consider suggesting such workarounds
> in each one of the above 3 situations.  Using breakpoints and returned
> values reported by `finish' are two very fundamental debugging
> techniques; telling the readers that they are simply unavailable will
> lead them to believe debugging code that uses inlined functions is
> next to impossible.

Is this better?

There are some ways that @value{GDBN} does not pretend that inlined
function calls are the same as normal calls:

@itemize @bullet
@item
You cannot set breakpoints on inlined functions.  @value{GDBN}
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 @value{GDBN}; until then,
set a breakpoint by line number on the first line of the inlined
function instead.

@item
Setting breakpoints at the call site of an inlined function may not
work, because the call site does not contain any code.  @value{GDBN}
may incorrectly move the breakpoint to the next line of the enclosing
function, after the call.  This limitation will be removed in a future
version of @value{GDBN}; until then, set a breakpoint on an earlier line
or inside the inlined function instead.

@item
@value{GDBN} cannot locate the return value of inlined calls after
using the @code{finish} command.  This is a limitation of compiler-generated
debugging information; after @code{finish}, you can step to the next line
and print a variable where your program stored the return value.

@end itemize

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2008-07-25 14:26 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-13 19:39 Daniel Jacobowitz
2008-06-13 19:43 ` Daniel Jacobowitz
2008-06-23 12:03 ` Jan Kratochvil
2008-06-23 14:23   ` Daniel Jacobowitz
2008-07-02 19:15   ` Daniel Jacobowitz
2008-07-03 11:22     ` [FYI] Inlining support, rough patch [break-by-function-name] Jan Kratochvil
2008-07-03 16:01       ` Daniel Jacobowitz
2008-07-12  7:41         ` Jan Kratochvil
2008-07-08  0:12     ` [FYI] Inlining support, rough patch Daniel Jacobowitz
2008-07-15 19:21 ` Daniel Jacobowitz
2008-07-17 23:53   ` Mark Kettenis
2008-07-18 13:03     ` Daniel Jacobowitz
     [not found]       ` <200807251446.m6PEkfwc027635@brahms.sibelius.xs4all.nl>
2008-07-25 17:47         ` Daniel Jacobowitz
2009-03-31  3:06           ` Tom Tromey
2009-03-31 20:49             ` Mark Kettenis
2009-03-31 22:13               ` Daniel Jacobowitz
2009-04-20 15:49               ` Daniel Jacobowitz
2009-04-20 15:54                 ` Jan Kratochvil
2009-06-27 18:01                   ` Daniel Jacobowitz
2009-06-28 10:16                     ` Jan Kratochvil
2009-06-28 13:35                       ` Daniel Jacobowitz
2009-06-30 16:11                       ` Tom Tromey
2009-06-30 16:50                         ` Jan Kratochvil
2009-04-22 22:04                 ` Mark Kettenis
2009-04-23  3:17                   ` Eli Zaretskii
2009-04-23  5:56                   ` Stan Shebs
2009-04-23 12:48                   ` Daniel Jacobowitz
2009-06-18 17:55                     ` Tom Tromey
2009-06-20  9:57                       ` Mark Kettenis
2009-06-20 19:28                         ` Samuel Bronson
2009-04-24 21:44                   ` Thiago Jung Bauermann
2008-07-18  2:02   ` Paul Pluzhnikov
2008-07-18  3:07     ` Daniel Jacobowitz
2008-07-20 14:41   ` Eli Zaretskii
2008-07-25 13:54   ` Eli Zaretskii
2008-07-25 14:26     ` Daniel Jacobowitz [this message]
2008-07-25 16:11       ` Daniel Jacobowitz
2008-07-26  5:58       ` Eli Zaretskii

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=20080725142551.GA15973@caradoc.them.org \
    --to=drow@false.org \
    --cc=eliz@gnu.org \
    --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