11.10.2010 23:14, Roland McGrath wrote:
It didn't occur to me last week to look for the .debug_aranges
section.
But I concur that it should be consistent: .debug_aranges should be exactly
the set of ranges (whatever that is) emitted for any compile_unit DIE.
That should likewise resolve to whatever specific empty range it is, not
absolute zeros. (I say so not because the relocated empty range seems
especially useful--it tells you nothing except what the link order of the
.o files happened to be--but just to stick to the aforementioned
consistency in a thorough way.)
So let's have main.c with just empty main function, and then two files
x.c and y.c, containing just int x and y respectively. We link them all
together to get:
[ b] compile_unit [...]
name (strp) "main.c"
low_pc (addr) 0x0000000000400474 <main>
high_pc (addr) 0x000000000040047a
[ 5f] compile_unit [...]
name (string) "x.c"
low_pc (addr) 0x000000000040047c
high_pc (addr) 0x000000000040047c
[ a8] compile_unit [...]
name (string) "y.c"
low_pc (addr) 0x000000000040047c
high_pc (addr) 0x000000000040047c
Now is that legal? If yes, then the debug_aranges can't be accurate for
that situation. If not, I'll have to add a check for that. (Which at
this point means probably just making XFAIL test case out of it.)
Handling empty ranges in dwarflint doesn't work, they are diagnosed as
error. If they should be accepted, then I guess only as a reciprocal
value to empty range in .debug_info. That kind of tracking is not there
either.
PM