On 18 Sep 2026, at 13:18, Markus Volk <[email protected]> wrote: > > That's what claude "thinks" about the issue:
Hmm. > 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. > What is the same on every architecture: > > meson passes the unity file to the compiler by its relative path, > gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c. Because gcc.bbclass adds > -fcanon-prefix-map, gcc canonicalises it and stores the remapped absolute > path as the CU name: > > DW_AT_name : > /usr/src/debug/gtk4/4.24.0/gtk/svg/libgtk_svg.a.p/gtk_svg-unity0.c > DW_AT_comp_dir : /usr/src/debug/gtk4/4.24.0 > > 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. > 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 reason is gcc's configure. On the arm cross compiler > HAVE_AS_WORKING_DWARF_N_FLAG is not defined, on x86-64 and aarch64 it is. > The preceding check "--gdwarf-4 with the APP marker" uses a hard-coded > "ret" instruction instead of $insn, which does not assemble on ARM: > > checking assembler for --gdwarf-4 with the APP marker > conftest.s:14: Error: bad instruction `ret' > > So the real check is never run, gas is not passed --gdwarf-5, and the > whole ".file 0" logic in dwarf2out.cc is disabled on 32-bit ARM. gcc then > emits the main file as ".file 1", which is exactly what dwarfsrcfiles > picks up. The ‘ret’ bug I’ve discussed with GCC, verified that s/ret/$insn/ is a good fix, and we can incorporate that. There’s multiple bugs here and working around them in GTK isn’t the best fix. Ross
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246218): https://lists.openembedded.org/g/openembedded-core/message/246218 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]] -=-=-=-=-=-=-=-=-=-=-=-
