This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils 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]

Re: dwarflint


>   [    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.)

Right.  I hadn't thought through the example to articulate it.  But this is
an example of why I was so dubious about empty ranges.  I don't see any
abstract rationale for it.  These two CUs cover no PCs at all, so I always
would have expected just no *_pc/ranges attributes at all there.

> 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.

Well, we have to decide whether we think GCC is wrong today and should be
fixed, or if its existing practice is kosher enough and then dwarflint
needs to accept it somehow.

The only rationale I've heard for empty ranges is Tom's idea that every CU
should be the rhs of some .debug_aranges entry just so you can be sure that
.debug_aranges is really complete (vs. a buggy old GCC, or some different
letter-of-DWARF producer where some CUs with actual PCs had no
.debug_aranges data emitted, is what I assume Tom must have in mind).  As
things stand in GCC, indeed these two CUs will both have entries there in
the linked output--conflicting matches for the same (empty) PC range with
different rhs in each.  That meets Tom's test.  But it's obviously not
actually useful in its own right.

The only possible rationale that I can think of that would really justify a
no-code CU producing any .debug_aranges entry as inherently useful is a
different one, that isn't satisfied today at all.  That is, if the "PC" set
that contributes to the *_pc/ranges attributes in the tree, and thus
matching in .debug_aranges, were to include not only PC addresses but data
addresses too.  Then e.g. the x.c CU above would have *_pc/ranges covering
the data address range indicated by the DW_AT_location DW_OP_addr &x.  This
is useful in that it makes it possible to do a by-address lookup of a data
address and resolve to the CU that contains some DIE with a fixed-address
location description, so you could quickly go from "tell me about 0x123" to
"that is 'x' and I know its type and decl coordinates et al".  But a) there
isn't actually any GDB feature that does a lookup in that direction (even
by slow exhaustive search means) today (p/a will just tell you about the
ELF symbol matches) and b) no producer has ever emitted .debug_aranges or
*_pc/ranges attributes taking data addresses into account, so you could not
really have a consumer depend on it in the foreseeable future.  So, I tend
to think that if this sort of use were any motivation at all, then it
should only be a consideration for some new kind of by-address quick index
scheme rather than shoehorning it into .debug_aranges.

In short, Petr has helped me become even more dubious about Tom's idea
that .debug_aranges getting anything at all for CUs without PCs is any
kind of useful.


Thanks,
Roland

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