[lldb-dev] breakpoint command

[Thirumurthi, Ashok]

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

FYI Mike, Daniel and I took care of most of the common DWARF4 issues this week.  So, hopefully you can get a clearer picture on the way forward with the prologue.

Specifically, we are looking at tests that are okay with -gdwarf-2 but fail with -3 or -4.  Cheers,


-        Ashok

From: lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu] On Behalf Of Michael Sartain
Sent: Wednesday, June 19, 2013 1:49 PM
To: jingham at apple.com
Cc: lldb-dev at cs.uiuc.edu
Subject: Re: [lldb-dev] breakpoint command

On Tue, Jun 18, 2013 at 6:58 PM, <jingham at apple.com<mailto: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<mailto: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/20130730/edc69464/attachment.html>