Home Original page

[BUG] Regression in 2.14.90 (relative to 2.13.90)

Carlo Wood carlo@alinoe.com
Wed Nov 26 02:13:00 GMT 2003 
On Tue, Nov 25, 2003 at 05:08:16PM -0800, H. J. Lu wrote:
> > Imho, this means that gdb is bugged, not ld.
> 
> There is a bug between gcc, binutils and gdb. Do you have a testcase
> similar to mine?

With Nick's patch I get the following for your testcase:

~/c++/tests/binutils>readelf -wl test

[..deleted..]

 The File Name Table:
  Entry Dir     Time    Size    Name
  1     0       0       0       test01a.cpp
  2     0       0       0       test01a.h

 Line Number Statements:
  Set File Name to entry 2 in the File Name Table
  Extended opcode 2: set Address to 0x8048564
  Special opcode 8: advance Address by 0 to 0x8048564 and Line by 3 to 4
  Special opcode 47: advance Address by 3 to 0x8048567 and Line by 0 to 4
  Advance PC by 21 to 804857c
  Extended opcode 1: End of Sequence

[..deleted..]

 The File Name Table:
  Entry Dir     Time    Size    Name
  1     0       0       0       test01c.cpp
  2     0       0       0       test01.h
  3     0       0       0       test01a.h

 Line Number Statements:
  Set File Name to entry 3 in the File Name Table
  Extended opcode 2: set Address to 0x0
  Special opcode 8: advance Address by 0 to 0x0 and Line by 3 to 4
  Special opcode 47: advance Address by 3 to 0x3 and Line by 0 to 4
  Advance PC by 21 to 18
  Extended opcode 1: End of Sequence

[..deleted..]


>From this I can derived that test01a.h:4 corresponds
with [0x8048564 - 0x804857c]

The fact that gdb sets a breakpoint in 0x0 is just plain wrong,
why would it do that?  The 0x0 in

  Set File Name to entry 3 in the File Name Table
  Extended opcode 2: set Address to 0x0
  Special opcode 8: advance Address by 0 to 0x0 and Line by 3 to 4

just means that that code doesn't exist.
It certainly doesn't exist at 0x0.

Please just let gdb ignore such entries with PC=0.

-- 
Carlo Wood <carlo@alinoe.com>
More information about the Binutils mailing list