This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [BUG] Regression in 2.14.90 (relative to 2.13.90)
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>