[PATCH] Fix -gdwarf-5 -gsplit-dwarf ICEs (PR debug/89498)

[Jakub Jelinek]

On Sat, Mar 09, 2019 at 03:12:28AM -0300, Alexandre Oliva wrote:
> Ugh.  That's more fallout from the concurrent implementations of v5 and
> LVU, ISTM.  My bad for not catching, no doubt, since LVU landed later; I
> don't mean to excuse it, just to explain how it came about.
> 
> 
> I'm afraid I hadn't thought of it to the point of saying what would be
> correct, let alone more desirable.  We're in non-strict dwarf territory,
> trying to extend something that was not designed to be extended.
> Unfortunately, the extensions designed for v4 do not work for v5, and
> the extensions proposed for v6 don't either, so we're in a bit of a
> limbo, so I guess anything that makes sense and doesn't break
> unsuspecting consumers will do.
> 
> 
> I'm thinking the most reasonable way forward in this non-standard
> minefield is to document that the section base address used for
> DW_AT_GNU_locviews is the same base address used for the corresponding
> loclistx table.  That would make it trivially correct for v4-, and
> not-so-trivially correct, but mostly sensible IMHO, for v5.
> 
> I'd argue there are even backward-compatibility reasons to document it
> that way, since it is not hard to figure out that this was (by inaction)
> the intent in the, erhm, reference implementation, even though, as you
> noticed, it didn't work for split v5.  Of course, since it was broken,
> it wouldn't be unreasonable to disregard backward compatibility
> altogether and go for something entirely different; I don't know of any
> other implementations that might have been based on this accidental
> implementation detail, and I'd assume that if anyone even noticed the
> problem while collecting data from the reference implementation, we'd
> have got a bug report about it shortly thereafter.
> 
> 
> Another possibility of encoding that comes to mind would be to output an
> offset between the LLST and the LVUS labels as DW_AT_GNU_locviews, but
> since it's not a compile-time constant, we won't want to make it
> uleb128.  It would still be resolved to a constant and avoid
> relocations, as preferred by split-dwarf, but it wouldn't save space or
> relocations WRT what we'd get after your corrective patch.
> 
> Yet another, more far-out possibilities, are to introduce a list of
> locview offsets right after the end of the loclist offsets, or even a
> separate section with a separate section header for them, so that we
> could use uleb128 compiler-computed indices to reference locview
> extensions to loclists.  That would be a significant amount of work for
> little to no benefit AFAICT, and only on the short term.  In the long
> term, I expect/hope some way to represent locviews to be adopted in
> standard DWARF.

Whatever we choose, IMHO: 1) we can't introduce new DW_FORM_*
2) we must avoid changing anything on how it was represented for the
non-split case, we've already shipped GCC 8.[123] with it
3) the consumer must be able to figure out easily according to clear rules
how to interpret the attribute and find the views.  So, either it needs
to use different form from what is used normally if it needs to be
interpreted differently, or it needs to use a different attribute,
and from that and possibly version number in .debug_info header it needs
to figure out if it should use absolute or relative offset to .debug_loc,
or absolute or relative offset to .debug_loclist, in split or non-split
case etc.  We need to look at what we emit with
-gdwarf-{2,3,4,5} {,-gsplit-dwarf}.

If we added offsets to LVU entries to the table at the start of
.debug_loclists, they shouldn't be counted towards the limit and guess some
locviews unaware consumers could be upset, because the uleb128s would be
above that limit.  If we include them in the limit, then even more consumers
would be upset because they don't find valid DW_LLE_* at those spots when
they just try to dump the .debug_loclists section without accessing
.debug_info.

	Jakub