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

On 15.07.2026 10:57, Kamil Bucki (Nokia) wrote:
> 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.

Sure, that's understood.

> 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.

Neither this nor ...

> 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).

... this helps me very much. I'm perhaps blind, but I can't spot anything
towards the encoding this patch is about, also not for DW_LLE_start_{end,length}.
Neither document mentions DW_LLE_offset_pair at all.

The proposal at dwarfstd.org is about Dwarf6 only anyway. The doc at fsfla.org
has a section on Dwarf2-5, ...

>   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.

... as would be relevant for this case, yet I can't spot anything towards the
encoding (the pair of uleb128-s) there either. Which leaves the compiler source
as the only reference. Yet how am I certain the compiler source is actually
doing things as intended?

Jan