Re: [FYI] Inlining support, rough patch

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 25 Jul 2008 10:25:51 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sourceware.org
> 
> > 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

Yes, thanks.