[lldb-dev] breakpoint command

[Michael Sartain]

On Tue, Jun 18, 2013 at 6:58 PM, <jingham at apple.com> wrote:

> > If we have no prologue_end marker, would it make sense to not skip
> anything?
>
> I don't know what more recent gcc's do, but they used to omit the
> prologue_end marker, and instead use the convention that the first line
> table entry for the function is the beginning of the function, and the
> second is the end of the prologue.  gdb has relied on that for a long long
> time (in absence of the prologue_end and back to the stabs days when there
> was no such thing.)  So not skipping the prologue in this case seems like
> throwing the baby out with the bath water.  Better would be to get your
> compiler to get it right...


On Wed, Jun 19, 2013 at 10:34 AM, Greg Clayton <gclayton at apple.com> wrote:

> I agree with Jim here and I would vote to still try and skip something.
> The strongest reason I have for this recommendation is that the debug info
> for args and locals _relies_ on being past the prologue, and doesn't
> describe the location correctly for the arguments and locals in the
> prologue. So when users set a breakpoint on "printf" and they stop there,
> all variable information is usually bogus until the prologue has been
> executed. Users don't like seeing garbage values (they file bugs) and then
> stepping over the first line and then saying "now the variables are
> correct".


I agree it'd be nice for the compiler to get it right, but we have folks
that are going to try to use this debugger, they're going to try to set a
breakpoint, and when it sets that breakpoint in the middle of the function
they will just switch back to gdb - they rightfully won't care about
prologue end markers or compiler bugs.

I'm all for figuring out how to skip something when we don't have that
info, but I'd prefer to error on the side of caution. Having some locals
with garbage in them seems better to me than having your breakpoint not hit
at all or hit after something important you wanted to debug.

For whatever it's worth, this is broken with gcc 4.6, and it appears to be
broken in gcc 4.8. It's tough to tell what happens with lldb & gcc 4.8
because something else is broken there - I think lldb has trouble with
dwarf4.

This is the debug_line info gcc 4.8 produces (identical to gcc 4.6) for the
little program down below.

.debug_line: line number info for a single cu
Source lines (from CU-DIE at .debug_info offset 0x0000000b):

            NS new statement, BB new basic block, ET end of text sequence
            PE prologue end, EB epilogue begin
            IA=val ISA number, DI=val discriminator value
<pc>        [row,col] NS BB ET PE EB IS= DI= uri: "filepath"
0x00400900  [   6, 0] NS uri: "/home/mikesart/data/src/blah2/blah.cpp"
0x00400932  [   6, 0] NS
0x00400959  [  10, 0] NS
0x00400986  [  11, 0] NS
0x004009ac  [  14, 0] NS
0x004009bc  [  15, 0] NS
0x004009be  [  18, 0] NS
0x004009cd  [  19, 0] NS
0x004009e1  [  20, 0] NS
0x004009e6  [  21, 0] NS
0x004009e8  [  21, 0] NS ET

   1 #include <stdio.h>
   2 #include <stdarg.h>
   3
   4 int
   5 myprintf (const char *format, ...)
   6 {
   7   va_list arg;
   8   int done;
   9
  10   va_start (arg, format);
  11   done = vfprintf (stdout, format, arg);
  12   va_end (arg);
  13
  14   return done;
  15 }
  16
  17 int main( int argc, char *argv[] )
  18 {
  19     myprintf("blah is %d\n", 5);
  20     return 0;
  21 }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130619/ba33a988/attachment.html>