Re: [PATCH] - Accept optional printed address at function breakpoints

[Fred Fish <fnf at ninemoons dot com>]

On Monday 08 December 2003 09:47, Daniel Jacobowitz wrote:
> >   $ gcc -g -o x x.c
>
> What GCC version?

gcc version 3.4 20031207 (experimental)

> This is a debug info bug.  Your patch is not correct; when you say
> "break LINE" or "break FUNCTION" and there is debug info, it's GDB's
> established behavior to stop at the beginning of a line.  By not
> allowing the address we verify that GDB is stopping at the beginning of
> a line as expected.

OK, though we might want to review the few places in the testsuite
that allow an optional address to ensure that we are enforcing this
behavior.

It's also interesting to read the comments in condbreak.exp:

  # GCC's Dwarf2 writer, on the other hand, squeezes out duplicate line
  # entries, so GDB considers the source line to begin at the start of
  # the function's prologue.  Thus, if the program stops at the
  # breakpoint, GDB will decide that the PC is not at the beginning of a
  # source line, and will print an address.
  #
  # I think the Dwarf2 writer's behavior is arguably correct, but not
  # helpful.  If the user sets a breakpoint at that source line, they
  # want that breakpoint to fall after the prologue.  Identifying the
  # prologue's code with the opening brace is nice, but it shouldn't
  # take precedence over real code.
  #
  # Until the Dwarf2 writer gets fixed, I'm going to XFAIL its behavior.

On one hand, I can see the value of having just a single test that
focuses on confirming/enforcing this behavior and be more lenient
about the patterns we accept in general.  On the other hand, I can see
that having dozens of new failures pop up due to a change in gcc debug
output could be helpful in getting enough attention to get the problem
fixed.

> This doesn't tell you anything.  Objdump -S will coalesce identical
> line notes.  You need to look at the debug info.  For instance:

Sorry, I should have mentioned that I also checked the debug output
with "dwarfdump", which produces:

line number info
<source>        [row,column]    <pc>    //<new statement or basic block
/build/sourceware/gdb/T-i686-pc-linux-gnu/gdb/x.c:      [  2,-1]        0       
// new statement
/build/sourceware/gdb/T-i686-pc-linux-gnu/gdb/x.c:      [  6,-1]        0x5     
// new statement
/build/sourceware/gdb/T-i686-pc-linux-gnu/gdb/x.c:      [  8,-1]        0x8     
// new statement
/build/sourceware/gdb/T-i686-pc-linux-gnu/gdb/x.c:      [ 11,-1]        0xa     
// new statement
/build/sourceware/gdb/T-i686-pc-linux-gnu/gdb/x.c:      [ 12,-1]        0x26    
// new statement
/build/sourceware/gdb/T-i686-pc-linux-gnu/gdb/x.c:      [ 13,-1]        0x2b    
// new statement
/build/sourceware/gdb/T-i686-pc-linux-gnu/gdb/x.c:      [ 14,-1]        0x30    
// new statement
/build/sourceware/gdb/T-i686-pc-linux-gnu/gdb/x.c:      [ 14,-1]        0x32    
// new statement        // end of text sequence

>  Line Number Statements:
>   Extended opcode 2: set Address to 0x8048334
>   Special opcode 6: advance Address by 0 to 0x8048334 and Line by 1 to 2
>   Special opcode 47: advance Address by 3 to 0x8048337 and Line by 0 to 2
>   Special opcode 36: advance Address by 2 to 0x8048339 and Line by 3 to 5
>   Special opcode 49: advance Address by 3 to 0x804833c and Line by 2 to 7
>   Special opcode 35: advance Address by 2 to 0x804833e and Line by 2 to 9
>   Special opcode 230: advance Address by 16 to 0x804834e and Line by 1 to
> 10 Special opcode 76: advance Address by 5 to 0x8048353 and Line by 1 to 11
> Special opcode 76: advance Address by 5 to 0x8048358 and Line by 1 to 12
> Advance PC by 2 to 804835a
>   Extended opcode 1: End of Sequence
>
> Notice the special opcode 47 which advances address, but not line?  GDB
> recognizes that and uses it to find the end of the prologue.  If you
> haven't got one of those, something is wrong.

Here is what I get from "readelf --debug-dump=line x" after compiling
my test case with "gcc -g -o x x.c":

 Line Number Statements:
  Extended opcode 2: set Address to 0x8048324
  Special opcode 6: advance Address by 0 to 0x8048324 and Line by 1 to 2
  Special opcode 79: advance Address by 5 to 0x8048329 and Line by 4 to 6
  Special opcode 49: advance Address by 3 to 0x804832c and Line by 2 to 8
  Special opcode 36: advance Address by 2 to 0x804832e and Line by 3 to 11
  Advance PC by constant 17 to 0x804833f
  Special opcode 160: advance Address by 11 to 0x804834a and Line by 1 to 12
  Special opcode 76: advance Address by 5 to 0x804834f and Line by 1 to 13
  Special opcode 76: advance Address by 5 to 0x8048354 and Line by 1 to 14
  Advance PC by 2 to 8048356
  Extended opcode 1: End of Sequence

The native RedHat 9 gcc (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
produces:

 Line Number Statements:
  Extended opcode 2: set Address to 0x80482f4
  Special opcode 6: advance Address by 0 to 0x80482f4 and Line by 1 to 2
  Special opcode 48: advance Address by 3 to 0x80482f7 and Line by 1 to 3
  Special opcode 36: advance Address by 2 to 0x80482f9 and Line by 3 to 6
  Special opcode 49: advance Address by 3 to 0x80482fc and Line by 2 to 8
  Special opcode 36: advance Address by 2 to 0x80482fe and Line by 3 to 11
  Special opcode 230: advance Address by 16 to 0x804830e and Line by 1 to 12
  Special opcode 76: advance Address by 5 to 0x8048313 and Line by 1 to 13
  Special opcode 76: advance Address by 5 to 0x8048318 and Line by 1 to 14
  Advance PC by 2 to 804831a
  Extended opcode 1: End of Sequence

and gdb on that executable does behave as the current testsuite expects:

  (gdb) br foo
  Breakpoint 1 at 0x80482f7: file x.c, line 3.
  (gdb) br bar
  Breakpoint 2 at 0x80482fc: file x.c, line 8.
  (gdb) run
  Starting program: /links3/build/sourceware/gdb/T-i686-pc-linux-gnu/gdb/x 

  Breakpoint 1, foo () at x.c:3
  3       }
  (gdb) c
  Continuing.
  
  Breakpoint 2, bar () at x.c:8
  8       }

So this does look like a regression in gcc debug output.  I hereby withdraw
my suggested patch.  :-)

-Fred