On 18 Sep 2026, at 17:17, Ross Burton <[email protected]> wrote:
>> The root cause is not in meson. It is the combination of a gcc configure
>> bug that only hits 32-bit ARM and a weakness in dwarfsrcfiles that hides
>> the problem everywhere else. That is why only beaglebone-alt failed and
>> why neither of us can reproduce it on x86-64.
> 
> Sounds like we’re fixing the wrong place.

I’ve just sent an oe-core patch to backport a now-upstream gcc fix for this.

>> dwarfsrcfiles unconditionally prints comp_dir + "/" + name for the CU, so
>> for an absolute name it produces a doubled path:
>>  
>> /usr/src/debug/gtk4/4.24.0//usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c
> 
> Bug in dwarfsrcfiles.  binutils has a tool now to do this (eu-srcfiles), so 
> I’m actually testing a build with that instead.

My test branch works but we can merge that post-release, as this is entirely 
unrelated to the issue.

>> What is different on ARM:
>> 
>> Whether the file is copied anyway depends on the line table. I built a
>> gcc-cross-arm and compiled a minimal unity file with both toolchains and
>> the same flags:
>> 
>>  x86-64: DWARF 5 line table built by gas, unity file only as entry 0,
>>          which dwarfsrcfiles skips (its loop starts at 1)
>>  arm:    DWARF 3 line table built by gas, unity file as entry 1,
>>          listed by dwarfsrcfiles as
>>          /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c
> 
> So is index 0 special? I don’t understand what’s happening here. I note that 
> eu-srcfiles and dwarfsrcfiles output slightly different things here, 
> specifically the unity file itself isn’t dumped by eu-srcfiles.

The actual reproducer is when a binary is built with dwarf5 data _and_ the 
source file doesn’t actually have any symbols, it doesn’t appear in the source 
file list.  I’ve filed a bug with elfutils 
(https://sourceware.org/bugzilla/show_bug.cgi?id=34666) for this edge case.  As 
the file has no definitions it’s not really a problem that it doesn’t get 
included in our debug sources file.

So, when the gcc fix is merged, we can take v1 of this upgrade without the 
workaround.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#246331): 
https://lists.openembedded.org/g/openembedded-core/message/246331
Mute This Topic: https://lists.openembedded.org/mt/121274837/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to