On Mar 6, 2019, Jakub Jelinek <ja...@redhat.com> wrote: > On Tue, Mar 05, 2019 at 04:06:59PM -0500, Jason Merrill wrote: >> > Assuming output_view_list_offset is correct, the following patch adjusts >> > size_of_die/value_format accordingly. >> >> I would guess that omitting the handling from output_view_list_offset was an >> oversight in the view work. Alex, which is right? :)
I guess both are :-) I don't recall having dealt with this particular combination of flags. Indeed, I'm pretty sure I wrote the bulk of the locview output support before DWARFv5 support was there, and AFAICT I failed to pick up the more compact DWARFv5 representation as I updated the patchset, proposed the locview extension for DWARFv6 in line with DWARFv5 locviews, and implemented it as the incompatv5 extension for v5 loclists with locviews that Jakub noticed. > In order to use DW_FORM_loclistx .uleb128 for the DW_AT_GNU_locviews, > we'd need to emit .long .LVUS0-.Ldebug_loc0 etc. next to the > .LLST0-.Ldebug_loc0 in the section offsets table at .Ldebug_loc0, > but I'd expect debug info consumers to assume that anything listed > in the offset table is actually a valid DW_LLE_* sequence, which is not the > case for the .LVUS* labels. *nod* > Note the > .long .LVUS0-.Ldebug_loc0 # DW_AT_GNU_locviews > looks weird, at least with the patch it is given DW_FORM_sec_offset, but > because it is a difference between .LVUS0-.Ldebug_loc0, it is actually not a > sec offset. Shall it use a different form in that case? 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. -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain Engineer Free Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
