This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

breakpoints/1102: prolog size calculated wrong?


>Number:         1102
>Category:       breakpoints
>Synopsis:       prolog size calculated wrong?
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 27 22:48:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     miwako dot tokugawa at intel dot com
>Release:        unknown-1.0
>Organization:
>Environment:
Linux:Itanium:dwarf
>Description:
I am attaching two binaries, "good.exe" and "bad.exe"
both of which are created from a same .o (class_7.o) but by linking with different set of libraries ("good" is linked with Intel libraries and "bad" is linked with gnu libraries on United Linux 1.0; the link commands used are captured in files good.link and bad.link) using Intel compiler.
When fed with "bad", gdb thinks "main" user wants (end of profile?) is at a higher address than it really is (=main + 0x71 while it really should be main + 0x22.)

I don't know if this is relevant, but info in .symtab (address of "main") and IA64.unwind (prolog size of "main") seem ok in both binaries. Debug info for class.o on both are also identical as expected.

-------------------------------------------
Detail:

In "good", the address of "main" gdb shows is 0x4000000000002282.
	(= 0x4000000000002260 + 0x 22)
In "bad", the address of "main" gdb shows is 0x40000000000007f1.
	(= 0x4000000000000780 + 0x 71)

Sanity Check 1.
"readelf -w" shows that the only address sequence that covers these adrresses
belong to class_7.cpp. (expected)

Sanity Check 2.
The Line Number Statements under class_7.cpp are identical in both binaries except
for the values of the relocated addresses. (expected).

Sanity Check 3.
Line Number Statement also shows that
in "good" binary,  0x2282 shows up on
	Special opcode 10: advance Address by 2 to 0x2282 and Line by 1 to 15
and that in "bad" binary, 0x7f1 shows up on 
	Advance PC by 79 to 7f1
	Advance Line by 1 to 16
This is why the line number associated with "main" are different.
This shows that debugger is translating address to line number correctly. (This still makes sense)

We're emitting DW_AT_low_pc for main as 0x2260 and 0x780 (both corresponding to line13), so 
the debugger obviously isn't counting on this.
>How-To-Repeat:
On "bad.exe", do
(gdb) b main
Breakpoint 1 at 0x40000000000007f1: file class_7.cpp, line 16.
>Fix:
I wish I knew. :-)
>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]