[llvm-dev] [DWARF] Handling empty ranges/location lists in ET_REL files

[James Henderson via llvm-dev]

Hi all,

I've put this email in a different thread, although it is quite similar to
some of the threads on tombstoning etc, with similar underlying structural
issues.

Whilst prototyping my fragmented DWARF idea for GC-ing DWARF sections
properly, I ran into an object in the game code I was using as my input
where a v4 .debug_loc section had a location description that looked
something like this:

.quad foo
.quad foo
... # location description

where foo was a section symbol, i.e. the start and end address were the
same. Consequently, there would be two relocations with 0 addend patching
the start and end offset. When I was using llvm-dwarfdump to dump the
.debug_loc section, I ended up with a decoding, and eventually a parsing
error, because it saw a 0, 0 pair, so treated the entry as an end of list
entry, and assumed the location description was the start of the next list.

The debug_loc parsing code treats 0, 0 pairs as end of list entries,
whether or not they are relocated. I think this is a bug - if there are
relocations we can be reasonably confident that the compiler did not intend
it to be the end of the list, and at link time, this probably won't get
resolved to 0, 0 (it's still technically possible it will, if 0 is a valid
address, and the corresponding section was put at that address, but that's
outside the scope of this email).

I've got a fairly simple change that could solve this, but it would require
to check for the presence of a relocation at either address, in the event
0, 0 was read. Should I go ahead with tidying up the change/testing it etc?
Or do we want a different solution to this problem (aside from using
DWARFv5 of course!)?

Related aside: I haven't checked, but it's quite possible there's a similar
problem in .debug_ranges parsing.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200721/41b39b85/attachment.html>