FW: [PATCH] readelf: attach location views to DW_LLE_startx_endx/startx_length loclists

[Kamil Bucki (Nokia)]

Hi,

Thanks for checking. You're right that there is no entry for DW_AT_GNU_locviews in the official DWARF standard - it isn't a standardized attribute. It's a GNU (GCC) extension ("Location Views" / LVU), so the lack of a spec in the DWARF documents is expected rather than a mistake on our side.



A few pointers:



  1.  Origin / status. It was introduced by Alexandre Oliva and merged into GCC 8 (patch series: https://gcc.gnu.org/legacy-ml/gcc-patches/2017-11/msg00820.html). It was proposed for standardization but is currently deferred, not accepted, by the DWARF committee: https://dwarfstd.org/issues/170427.1.html. The closest thing to a written specification is the author's own design document: http://www.fsfla.org/~lxoliva/papers/sfn/dwarf6-sfn-lvu.txt (defines DW_AT_GNU_locviews, code 0x2137, its semantics and encoding).



  1.  It's emitted by stock GCC. With -gdwarf-5 and optimization (-O2/-O3), GCC produces location lists and, by default (-gvariable-location-views=auto), augments them with location views, emitting DW_AT_GNU_locviews pointing at view-pair lists placed right before the corresponding location list. The relevant source is:



*         include/dwarf2.def - the attribute definition (DW_AT_GNU_locviews, 0x2137)

*         gcc/dwarf2out.{c,cc} - the emission logic: dwarf2out_locviews_in_attribute(), add_AT_view_list(), loc_list_has_views(), output_loc_list() / dwarf2out_maybe_output_loclist_view_pair() (which write the view pairs as uleb128 pairs ahead of the range they apply to).



So this isn't something exotic - it's produced by a standard gcc -gdwarf-5 -O3 build, which is exactly the case in this report.

Kamil



-----Original Message-----
From: Jan Beulich <jbeulich@suse.com>
Sent: Friday, July 10, 2026 3:22 PM
To: Kamil Bucki (Nokia) <kamil.bucki@nokia.com>
Cc: nickc@redhat.com; avieira@gcc.gnu.org; binutils@sourceware.org
Subject: Re: FW: [PATCH] readelf: attach location views to DW_LLE_startx_endx/startx_length loclists



[You don't often get email from jbeulich@suse.com<mailto:jbeulich@suse.com>. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]



CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.







On 09.07.2026 10:40, Kamil Bucki (Nokia) via Binutils wrote:

> display_loclists_list only read the GNU location-view pair

> (DW_AT_GNU_locviews) for DW_LLE_offset_pair, DW_LLE_start_end and

> DW_LLE_start_length entries.  For the indexed bounded forms

> DW_LLE_startx_endx and DW_LLE_startx_length the range was decoded but

> the matching view pair was left unread, so vstart lagged behind next

> and the adjacency heuristic emitted a spurious

>

>   Warning: Hole and overlap detection requires adjacent view lists and loclists.

>

> Add the two indexed bounded forms to the guard so their view pair is

> consumed and printed like the other bounded entries.  This is not

> target specific; it reproduces on any DWARF 5 object whose producer

> emits

> startx_* loclist entries together with location views.

>

>       PR binutils/34366

>       * dwarf.c (display_loclists_list): Also read and print the

>       location view pair for DW_LLE_startx_endx and

>       DW_LLE_startx_length entries.

>

> Signed-off-by: Kamil Bucki <kamil.bucki@nokia.com<mailto:kamil.bucki@nokia.com>>



While this looks entirely plausible, I wanted to check it against some kind of spec. Thing is - I don't appear to be able to locate such a spec for DW_AT_GNU_locviews (which is what I think would be relevant here). Can you perhaps provide a pointer?



Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20260715/ad7756e5/attachment.htm>