Re: [RFA] Testcase for backtrace/1435

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

I see the same FAIL that David Carlton is seeing.  This happens with
dwarf-2 on all my versions of gcc and binutils.  It doesn't happen
with stabs+.

The problem is with the dwarf-2 line table.  Look at this gdb output:

  (gdb) print &main
  $1 = (<text variable, no debug info> *) 0x8048358 <main>

  (gdb) break main
  Breakpoint 1 at 0x804834c: file /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.arch/i386-unwind.c, line 26.

0x804834c is a lot different from 0x8048358!

The source code is:

  trap () { ... }
  asm ( ... "gdb1435" ... )
  asm ( ... "main" ... )

And the addresses in the executable file are:

  (gdb) disass trap
  Dump of assembler code for function trap:
  0x08048348 <trap+0>:    push   %ebp
  0x08048349 <trap+1>:    mov    %esp,%ebp
  0x0804834b <trap+3>:    int3
  0x0804834c <trap+4>:    pop    %ebp
  0x0804834d <trap+5>:    ret
  End of assembler dump.

  (gdb) disass gdb1435
  Dump of assembler code for function gdb1435:
  0x08048350 <gdb1435+0>: push   %ebp
  0x08048351 <gdb1435+1>: mov    %esp,%ebp
  0x08048353 <gdb1435+3>: call   0x8048348 <trap>
  End of assembler dump.

  (gdb) disass main
  Dump of assembler code for function main:
  0x08048358 <main+0>:    push   %ebp
  0x08048359 <main+1>:    mov    %esp,%ebp
  0x0804835b <main+3>:    call   0x8048350 <gdb1435>
  End of assembler dump.

In the source code, line 26 is the closing brace of the "trap" function.
All the assembly code after that gets associated with this line!
"break main" calls find_pc_sect_line to map the address of "main"
onto a line number, comes up with 26, and sets the breakpoint on line 26.

I watched this happening by stepping through find_pc_sect_line.

"readelf -wl i386-unwind" gives this line table:

 Line Number Statements:
  Extended opcode 2: set Address to 0x8048348
  Advance Line by 23 to 24
  Copy
  Special opcode 48: advance Address by 3 to 0x804834b and Line by 1 to 25
  Special opcode 20: advance Address by 1 to 0x804834c and Line by 1 to 26
  Advance PC by 20 to 8048360
  Extended opcode 1: End of Sequence

In contrast, when I compile with -gstabs+ rather than -gdwarf-2, the
line table entry for line 26 ends at the end of the "trap" function like
it's supposed to.  find_pc_sect_line sees that the pc for "main" is not
associated with any line and does not adjust it to the beginning of the
line.

This is a bug somewhere, but I don't know where:

  It could be a bug in the test program i386-unwind.c.  There's not
  really a spec for how to write mixed C / assembly and have debugging
  work.  But i386-unwind.c is not that tricky.

  It could be a bug in the gcc dwarf-2 writer.  Look at the output
  of "readelf -wl" and ask yourself if "Advance PC by 20 to 8048360"
  is correct.

  Or it could be a bug in gdb.  I doubt this, because I bet that gdb
  is just reading the line table that it's given.

I am going to file a gdb PR.  If we decide that there is a gcc bug then
we can file a gcc PR.  And, we can either change the test script or
KFAIL this test.

dc> (though the tests themselves still execute and pass,
dc> which I don't quite understand).

Well, the test script wants to do "break main; run" to get to "main"
and then "continue" to get to the "int $3" instruction.  Instead,
"break main" gets set right after the "int $3", and then "run"
runs all the way to the "int $3".  Then the "continue" hits the
same SIGTRAP again.  It's really co-incidental that the target
program ends up at or near the right $PC.

Michael C