Re: [DWARF] Tracking uninitialized variables

[Michael Eager <eager at eagerm dot com>]

On 07/20/2015 09:55 AM, Nikolai Bozhenov wrote:
> On 07/17/2015 08:31 PM, Michael Eager wrote:

> > A related issue is where the breakpoint is taken.  GCC sets breakpoints
> > at the first instruction generated for a statement, which in this case,
> > appears to be before any of the arguments to bar are evaluated.  A
> > possibly better location would be after arguments are evaluated, before
> > the call is executed.

> In this case GDB set the breakpoint at the instruction at 0x0d where
> evaluation of the first argument for the call is performed. I'm not
> sure that there is a less confusing way to choose an address to set a
> breakpoint. For example I don't think it is a good idea to ignore
> evaluation of function arguments and set a breakpoint right at the
> call instruction. But even if there is a better way, such new feature
> is likely to be implemented in GDB rather than in GCC.

Debugging optimized programs is difficult, and deciding the best
location to set a breakpoint is a matter for some thought.  (See
Caroline Tice's dissertation.)  If none of the arguments is evaluated
until after the first instruction of a function call, then you cannot
display the argument values if that is your breakpoint.

No matter what location you feel is the best for a breakpoint, it is
the compiler which generates the line number table and indicates where
a breakpoint should be placed, not the debugger.  Don't expect anything
in GDB which will do something when GCC provides incomplete or
inaccurate information.


--
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077