------- Additional Comments From dberlin at gcc dot gnu dot org 2004-12-26
00:56 -------
The bug is in both readelf and a gcc bug.
The warning in readelf is a bug.
One can see by looking at the assembly that their is exactly one debug_loc
section, and exactly one debug_info section, in the object file. Thus, the bug
is cleraly in readelf.
Looking at the readelf source shows the bug quite clearly in display_debug_loc:
It assumes that each compilation unit only has one location list.
It has an outer loop going through the entire debug_loc section, and increments
comp_unit and breaks the inner loop when begin && end == 0, so that a unit with
more than one location list will always issue this warning.
However, the begin and end == 0 means it's the end of the location list, not the
end of the *debug_loc* section, or the debug_loc section for a given
compilation unit. There are no terminators in debug_loc for each compilation
unit that gets info from debug_loc, so this code can't work as written.
In short, there is no backpointer from location list to compilation unit, or way
to get a cu number from counting location lists in the section, so randomly
incrementing the comp_unit number and then saying "we can't find compilation
unit 1" when the location list is clearly referenced from unit 0, is a bogus
warning.
The only true way to fix this is to get the list of location lists for a given
compilation unit from the debug info dies, then printing them separately (or you
could print them inline as you see them).
So as of right now, the readelf code is broken.
The gdb problem (and i'm guessing this is the cause) appears to be a gcc one.
What happens is that one entry our location list ends up spanning a basic block,
but a no actual instructions, apparently.
.LVL2:
.L4:
# basic block 2
.LVL3:
This makes the beginning and end ranges of the location list entry the same,
which is invalid according to the standard (which specifies that the ending
address *must* be greated than the beginning address. See 2.5.4 in the dwarf3
standard)
I'm guessing this is what cuases gdb problems. At least, that's the only thing
visibly wrong with the dwarf2 output.
I will see if i can fix this in gcc.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |nickc at redhat dot com
AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2004-12-26 00:56:26
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19124
