[Dwarf-Discuss] question about [0x0..0xffffffff] location list entry

[Roland McGrath]

> > In this case, the LocList violates the requirements for an
> > ending address.
> [...]
> > The correct LocList for this variable would be [0..0xffffffff].
> 
> I am just a little confused by your last sentence.  In offsets,
> in the debug_loc section, are 0..0xffffffff, but once we add
> the base address, we get the strange empty range.  GDB treated
> that range as empty, so were we correct? 

If we were to assume "normal wrapping arithmetic" in the CU address_size
(which I think should be called invalid too, but anyway), this entry is
invalid on its face.  As wrapped, the ending address is less than the
beginning address.  The paragraph Michael cited says that's invalid.
That's different from an empty range.

> If we were, out of curiosity, how would one get the LocList above?

If the relevant base address for that entry is B, then the location list
entry would contain a beginning address of (-B) and an ending address of
(0xffffffff-B).  As I just said above, nobody should be assuming that
expecting the consumer to do wrapping arithmetic like that is valid.  But,
in practice, if this entry had used those values, then the calculation that
GDB did would have come out so that the entry spanned [0,0xffffffff) and it
would have behaved as the producer apparently intended it to.  Of course,
as I mentioned before, when the intent is "applies to all addresses", the
proper thing to do is not to use a location list at all, but just a single
location description.


Thanks,
Roland