diff mbox series

readelf: attach location views to DW_LLE_startx_endx/startx_length loclists

Message ID AM8PR07MB8310A1AD8CF6A572F05DBE49EDFE2@AM8PR07MB8310.eurprd07.prod.outlook.com
State New
Headers
Series readelf: attach location views to DW_LLE_startx_endx/startx_length loclists |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_binutils_build--master-arm success Build passed
linaro-tcwg-bot/tcwg_binutils_build--master-aarch64 success Build passed
linaro-tcwg-bot/tcwg_binutils_check--master-aarch64 success Test passed
linaro-tcwg-bot/tcwg_binutils_check--master-arm success Test passed

Commit Message

Kamil Bucki \(Nokia\) July 9, 2026, 8:40 a.m. UTC 
  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>
---
 binutils/dwarf.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Jan Beulich July 10, 2026, 1:22 p.m. UTC | #1 
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>

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
Kamil Bucki \(Nokia\) July 15, 2026, 8:57 a.m. UTC | #2 
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
Jan Beulich July 17, 2026, 8:11 a.m. UTC | #3 
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
diff mbox series

Patch

diff --git a/binutils/dwarf.c b/binutils/dwarf.c
index 829bcb761f7..d3e101704ca 100644
--- a/binutils/dwarf.c
+++ b/binutils/dwarf.c
@@ -8177,7 +8177,9 @@  display_loclists_list (struct dwarf_section *  section,
 
       if (vstart && (llet == DW_LLE_offset_pair
 		     || llet == DW_LLE_start_end
-		     || llet == DW_LLE_start_length))
+		     || llet == DW_LLE_start_length
+		     || llet == DW_LLE_startx_endx
+		     || llet == DW_LLE_startx_length))
 	{
 	  off = offset + (vstart - *start_ptr);