Some package builds fail because 'debugedit' cannot read debug sections

kashyapc commented

2025-11-27 14:18:11 +00:00

Owner

Description

Some package builds seem to fail with 'debugedit' being unable to read debug info. An example from 'qt5-qttools'[1] build failure:

[...]
debugedit:
/builddir/build/BUILD/qt5-qttools-5.15.18-build/BUILDROOT/usr/bin/lupdate-qt5:
Bad string pointer index 4006 for unit name (.debug_line_str)

debugedit:
/builddir/build/BUILD/qt5-qttools-5.15.18-build/BUILDROOT/usr/bin/qdoc:
Bad string pointer index 4274 for unit name (.debug_line_str)
[...]

[1] https://riscv-koji.fedoraproject.org/koji/buildinfo?buildID=53561

## Description Some package builds seem to fail with 'debugedit' being unable to read debug info. An example from 'qt5-qttools'[1] build failure: [...] debugedit: /builddir/build/BUILD/qt5-qttools-5.15.18-build/BUILDROOT/usr/bin/lupdate-qt5: Bad string pointer index 4006 for unit name (.debug_line_str) debugedit: /builddir/build/BUILD/qt5-qttools-5.15.18-build/BUILDROOT/usr/bin/qdoc: Bad string pointer index 4274 for unit name (.debug_line_str) [...] [1] https://riscv-koji.fedoraproject.org/koji/buildinfo?buildID=53561

lzampier commented

2025-12-04 15:50:45 +00:00

These are the packages I’ve found so far that are affected by the debugedit issue:
plplot - '/usr/bin/debugedit: Bad string pointer index ...'
unison - '/usr/bin/debugedit: Bad string pointer index ...'
scipy - '/usr/bin/debugedit: Bad string pointer index ...'
ghc9.2 - '/usr/bin/debugedit: Cannot handle 8-byte build ...'

These are the packages I’ve found so far that are affected by the debugedit issue: plplot - '/usr/bin/debugedit: Bad string pointer index ...' unison - '/usr/bin/debugedit: Bad string pointer index ...' scipy - '/usr/bin/debugedit: Bad string pointer index ...' ghc9.2 - '/usr/bin/debugedit: Cannot handle 8-byte build ...'

hrw commented

2025-12-11 12:50:44 +00:00

Member

dolphin-emu:
/usr/bin/debugedit: /builddir/build/BUILD/dolphin-emu-2503a-build/BUILDROOT/usr/bin/dolphin-emu-nogui: Bad string pointer index 4294966803 for unit name (.debug_line_str)
/usr/bin/debugedit: /builddir/build/BUILD/dolphin-emu-2503a-build/BUILDROOT/usr/bin/dolphin-tool: Bad string pointer index 4294966803 for unit name (.debug_line_str)

dolphin-emu: /usr/bin/debugedit: /builddir/build/BUILD/dolphin-emu-2503a-build/BUILDROOT/usr/bin/dolphin-emu-nogui: Bad string pointer index 4294966803 for unit name (.debug_line_str) /usr/bin/debugedit: /builddir/build/BUILD/dolphin-emu-2503a-build/BUILDROOT/usr/bin/dolphin-tool: Bad string pointer index 4294966803 for unit name (.debug_line_str)

hrw commented

2025-12-12 09:23:14 +00:00

Member

rkward: /usr/bin/ld: /usr/lib64/lp64d/libc_nonshared.a(pthread_atfork.oS): access beyond end of merged section (341)

https://riscv-koji.fedoraproject.org/koji/taskinfo?taskID=113420

rkward: /usr/bin/ld: /usr/lib64/lp64d/libc_nonshared.a(pthread_atfork.oS): access beyond end of merged section (341) https://riscv-koji.fedoraproject.org/koji/taskinfo?taskID=113420

hrw commented

2025-12-12 15:39:06 +00:00

Member

lfortran: /usr/bin/debugedit: Bad string pointer index 4294967294 (.debug_line_str)

kashyapc commented

2025-12-15 12:43:00 +00:00

Author

Owner

I just had a chat with Nick Clifton about this, and this is his explanation about the investigation (posting here with his permission):

What appears to be happening is that some riscv object files contain "bad" relocations that are supposed to put the correct offsets from places in the .debug_info section to strings in the .debug_line_str section. (and possibly the .debug_str section too, although I have not confirmed this). I put "bad" in quotes because the relocations do actually work, but only when the object file is examined in isolation. When the object file is linked into an executable and the contents of the .debug_line_str section are merged with other .debug_line_str sections in other object files, the relocations are not updated correctly and the result is that the executable ends up with entries in the .debug_info section that refer to bogus offsets in the .debug_line_str section. The reason that these relocations are "bad" is that they reference local symbols that are placed beyond the end of the .debug_line_str section. Such symbols are not adjusted when the .debug_line_str section is merged, which is why things break.

That is as far as I have gotten in my investigation. To proceed we need to find out if it is the assembler that is placing these symbols beyond the end of the .debug_line_str section, or if it is gcc telling the assembler to place them there. For that to happen someone needs to build a problematic object file with the --save-temps option added to the gcc command line, and then the assembler output from gcc needs to be examined.

Once I learn enough about this issue, Nick also suggested to file an upstream binutils bug, to start with.

I just had a chat with Nick Clifton about this, and this is his explanation about the investigation (posting here with his permission): > What appears to be happening is that some riscv object files contain "bad" relocations that are supposed to put the correct offsets from places in the .debug_info section to strings in the .debug_line_str section. (and possibly the .debug_str section too, although I have not confirmed this). I put "bad" in quotes because the relocations do actually work, but only when the object file is examined in isolation. When the object file is linked into an executable and the contents of the .debug_line_str section are merged with other .debug_line_str sections in other object files, the relocations are not updated correctly and the result is that the executable ends up with entries in the .debug_info section that refer to bogus offsets in the .debug_line_str section. The reason that these relocations are "bad" is that they reference local symbols that are placed beyond the end of the .debug_line_str section. Such symbols are not adjusted when the .debug_line_str section is merged, which is why things break. > > That is as far as I have gotten in my investigation. To proceed we need to find out if it is the assembler that is placing these symbols beyond the end of the .debug_line_str section, or if it is gcc telling the assembler to place them there. For that to happen someone needs to build a problematic object file with the --save-temps option added to the gcc command line, and then the assembler output from gcc needs to be examined. Once I learn enough about this issue, Nick also suggested to file an upstream binutils bug, to start with.

davidlt commented

2025-12-15 16:57:35 +00:00

Owner

@hrw Nick asked for libgcc.a rebuild with -save-temps and probably we also need -S.

I think that what is needed are the .s files from building bits of libgcc
Specifically any of: __gcc_bcmp.s, eqtf2.s, getf2.s, fixunstfsi.s,
floatunsitf.s, fixtfdi.s and more. In fact just build libgccc.a with
--save-temps and archive the lot!

From Matrix chat some ideas I had:

I guess the idea would be to modify this: https://src.fedoraproject.org/rpms/gcc/blob/rawhide/f/gcc.spec#_1342
--enable-bootstrap -> --disable-bootstrap
--enable-languages=c,[..] -> --enable-languages=c
profiledbootstrap -> all-gcc or maybe even libgcc.a
Of course, rpmbuild should have --noclean and I would place exit 1 right after make.
Actually you might need -save-temps -S (to get assembly files too).
Then re-run just libgcc.a bit with them, or mod the spec, not sure.
I am not sure we can build libgcc.a with a host compiled without doing building at least the C compiler.

It would be easiest if we could recompile libgcc.a with host compiler without rebuilding minimal GCC (with C enabled).

@hrw Nick asked for libgcc.a rebuild with -save-temps and probably we also need -S. > I think that what is needed are the .s files from building bits of libgcc > Specifically any of: __gcc_bcmp.s, eqtf2.s, getf2.s, fixunstfsi.s, > floatunsitf.s, fixtfdi.s and more. In fact just build libgccc.a with > --save-temps and archive the lot! From Matrix chat some ideas I had: > I guess the idea would be to modify this: https://src.fedoraproject.org/rpms/gcc/blob/rawhide/f/gcc.spec#_1342 > --enable-bootstrap -> --disable-bootstrap > --enable-languages=c,[..] -> --enable-languages=c > profiledbootstrap -> all-gcc or maybe even libgcc.a > Of course, rpmbuild should have --noclean and I would place exit 1 right after make. > Actually you might need -save-temps -S (to get assembly files too). > Then re-run just libgcc.a bit with them, or mod the spec, not sure. > I am not sure we can build libgcc.a with a host compiled without doing building at least the C compiler. It would be easiest if we could recompile libgcc.a with host compiler without rebuilding minimal GCC (with C enabled).

kashyapc commented

2025-12-16 10:24:02 +00:00

Author

Owner

[...]

Once I learn enough about this issue, Nick also suggested to file an upstream binutils bug, to start with.

Here we go: https://sourceware.org/bugzilla/show_bug.cgi?id=33723

[...] > Once I learn enough about this issue, Nick also suggested to file an upstream binutils bug, to start with. Here we go: https://sourceware.org/bugzilla/show_bug.cgi?id=33723

kashyapc referenced this issue

2025-12-17 11:08:11 +00:00

Re-enable debuginfo package creation for 'qt6-qtshadertools' #5

hrw commented

2025-12-19 13:30:03 +00:00

Member

bcc:
/usr/bin/ld: /usr/lib64/libbpf.a(btf.o): access beyond end of merged section (603)
/usr/bin/ld: /usr/lib64/libbpf.a(btf.o): access beyond end of merged section (594)
/usr/bin/ld: /usr/lib64/libbpf.a(libbpf.o): access beyond end of merged section (750)
/usr/bin/ld: /usr/lib64/libbpf.a(ringbuf.o): access beyond end of merged section (431)
/usr/bin/ld: /usr/lib64/libbpf.a(usdt.o): access beyond end of merged section (504)
/usr/bin/ld: /usr/lib64/libbpf.a(zip.o): access beyond end of merged section (314)
/usr/bin/ld: /usr/lib64/libbpf.a(elf.o): access beyond end of merged section (329)
/usr/bin/ld: /usr/lib64/libbpf.a(btf_relocate.o): access beyond end of merged section (240)

`bcc`: /usr/bin/ld: /usr/lib64/libbpf.a(btf.o): access beyond end of merged section (603) /usr/bin/ld: /usr/lib64/libbpf.a(btf.o): access beyond end of merged section (594) /usr/bin/ld: /usr/lib64/libbpf.a(libbpf.o): access beyond end of merged section (750) /usr/bin/ld: /usr/lib64/libbpf.a(ringbuf.o): access beyond end of merged section (431) /usr/bin/ld: /usr/lib64/libbpf.a(usdt.o): access beyond end of merged section (504) /usr/bin/ld: /usr/lib64/libbpf.a(zip.o): access beyond end of merged section (314) /usr/bin/ld: /usr/lib64/libbpf.a(elf.o): access beyond end of merged section (329) /usr/bin/ld: /usr/lib64/libbpf.a(btf_relocate.o): access beyond end of merged section (240)

yaneti commented

2025-12-19 14:56:59 +00:00

I've commented on the upstream bugreport with a a libbpf mock buildroot with -save-temps , hope that helps

hrw commented

2026-01-02 13:22:04 +00:00

Member

gprbuild:
debugedit: /builddir/build/BUILD/gprbuild-25.0.0-build/BUILDROOT/usr/bin/gprconfig: Bad string pointer index 4294967154 for unit name (.debug_line_str)
debugedit: /builddir/build/BUILD/gprbuild-25.0.0-build/BUILDROOT/usr/bin/gprclean: Bad string pointer index 4294967226 for unit name (.debug_line_str)
debugedit: /builddir/build/BUILD/gprbuild-25.0.0-build/BUILDROOT/usr/bin/gprbuild: Bad string pointer index 4294967101 for comp_dir (.debug_line_str)
debugedit: /builddir/build/BUILD/gprbuild-25.0.0-build/BUILDROOT/usr/bin/gprinstall: Bad string pointer index 4294967138 for unit name (.debug_line_str)

`gprbuild`: debugedit: /builddir/build/BUILD/gprbuild-25.0.0-build/BUILDROOT/usr/bin/gprconfig: Bad string pointer index 4294967154 for unit name (.debug_line_str) debugedit: /builddir/build/BUILD/gprbuild-25.0.0-build/BUILDROOT/usr/bin/gprclean: Bad string pointer index 4294967226 for unit name (.debug_line_str) debugedit: /builddir/build/BUILD/gprbuild-25.0.0-build/BUILDROOT/usr/bin/gprbuild: Bad string pointer index 4294967101 for comp_dir (.debug_line_str) debugedit: /builddir/build/BUILD/gprbuild-25.0.0-build/BUILDROOT/usr/bin/gprinstall: Bad string pointer index 4294967138 for unit name (.debug_line_str)

hrw commented

2026-01-02 19:34:16 +00:00

Member

pypy:
[platform:WARNING] /usr/bin/ld: /usr/lib64/lp64d/libc_nonshared.a(pthread_atfork.oS): access beyond end of merged section (341)
[platform:WARNING] /usr/bin/ld: /usr/lib64/lp64d/libc_nonshared.a(pthread_atfork.oS): access beyond end of merged section (341)

`pypy`: [platform:WARNING] /usr/bin/ld: /usr/lib64/lp64d/libc_nonshared.a(pthread_atfork.oS): access beyond end of merged section (341) [platform:WARNING] /usr/bin/ld: /usr/lib64/lp64d/libc_nonshared.a(pthread_atfork.oS): access beyond end of merged section (341)

hrw commented

2026-01-06 12:02:12 +00:00

Member

webkitgtk:
Extracting debug info from 17 files
/usr/bin/debugedit: Bad string pointer index 27023 (.debug_line_str)
/usr/bin/debugedit: Bad string pointer index 123166 (.debug_line_str)
/usr/bin/debugedit: Bad string pointer index 123069 (.debug_line_str)

`webkitgtk`: Extracting debug info from 17 files /usr/bin/debugedit: Bad string pointer index 27023 (.debug_line_str) /usr/bin/debugedit: Bad string pointer index 123166 (.debug_line_str) /usr/bin/debugedit: Bad string pointer index 123069 (.debug_line_str)

hrw commented

2026-01-07 11:23:24 +00:00

Member

systemd:
/usr/bin/ld: /usr/lib64/lp64d/libc_nonshared.a(pthread_atfork.oS): access beyond end of merged section (341)

`systemd`: /usr/bin/ld: /usr/lib64/lp64d/libc_nonshared.a(pthread_atfork.oS): access beyond end of merged section (341)

kashyapc commented

2026-01-12 13:55:03 +00:00

Author

Owner

I reproduced this problem in a container, details here: https://sourceware.org/bugzilla/show_bug.cgi?id=33723#c11

Also, from the reproducer container, I exctracted two 'libtclstub.a' files (a good and a bad one):

I got the "good" one from here (before applying add-determinism):

$ file /root/rpmbuild/BUILD/tcl-9.0.2-build/tcl9.0.2/unix/*.a
/root/rpmbuild/BUILD/tcl-9.0.2-build/tcl9.0.2/unix/libtclstub.a: current ar archive

This is the bad one (after applying add-determinism):

$ file /root/rpmbuild/BUILD/tcl-9.0.2-build/BUILDROOT/usr/lib64/*.a
/root/rpmbuild/BUILD/tcl-9.0.2-build/BUILDROOT/usr/lib64/libtclstub.a: current ar archive

I ran a diff with a couple of commands (xxd and ar):

$ diff -u <(xxd -a GOOD-libtclstub.a) <(xxd -a BAD-libtclstub.a)

--- /dev/fd/63	2026-01-12 12:16:42.798422879 +0000
+++ /dev/fd/62	2026-01-12 12:16:42.798422879 +0000
@@ -1,11 +1,11 @@
 00000000: 213c 6172 6368 3e0a 2f20 2020 2020 2020  !<arch>./       
-00000010: 2020 2020 2020 2020 3137 3637 3937 3137          17679717
-00000020: 3238 2020 3020 2020 2020 3020 2020 2020  28  0     0     
+00000010: 2020 2020 2020 2020 3137 3531 3933 3238          17519328
+00000020: 3030 2020 3020 2020 2020 3020 2020 2020  00  0     0     
 00000030: 3020 2020 2020 2020 3239 3420 2020 2020  0       294     
 00000040: 2020 600a 0000 000e 0000 01bc 0000 01bc    `.............
 00000050: 0000 01bc 0000 01bc 0000 01bc 0000 01bc  ................
-00000060: 0003 4af8 0003 4af8 0003 c684 0006 8920  ..J...J........ 
-00000070: 0006 8920 0009 8884 0009 8884 0009 8884  ... ............
+00000060: 0003 4ad0 0003 4ad0 0003 c634 0006 88a8  ..J...J....4....
+00000070: 0006 88a8 0009 87d4 0009 87d4 0009 87d4  ................
 00000080: 5463 6c5f 496e 6974 5374 7562 7300 7463  Tcl_InitStubs.tc
 00000090: 6c53 7475 6273 4861 6e64 6c65 0074 636c  lStubsHandle.tcl
 000000a0: 496e 7450 6c61 7453 7475 6273 5074 7200  IntPlatStubsPtr.
@@ -29,10 +29,10 @@
 000001c0: 7475 624c 6962 2e6f 2f20 2020 3137 3531  tubLib.o/   1751
 000001d0: 3933 3238 3030 2020 3020 2020 2020 3020  932800  0     0 
 000001e0: 2020 2020 3130 3036 3434 2020 3231 3532      100644  2152
-000001f0: 3936 2020 2020 600a 7f45 4c46 0201 0100  96    `..ELF....
+000001f0: 3536 2020 2020 600a 7f45 4c46 0201 0100  56    `..ELF....
 00000200: 0000 0000 0000 0000 0100 f300 0100 0000  ................
 00000210: 0000 0000 0000 0000 0000 0000 0000 0000  ................
-00000220: 0042 0300 0000 0000 0500 0000 4000 0000  .B..........@...
+00000220: d841 0300 0000 0000 0500 0000 4000 0000  .A..........@...
 00000230: 0000 4000 1c00 1b00 5971 a2f0 a6ec 8018  ..@.....Yq......
 00000240: 86f4 4168 1308 08f0 9704 0000 83b4 0400  ..Ah............
 00000250: 0567 b287 3378 0601 2330 04fc 9060 233c  .g..3x..#0...`#<

And the diff with ar indicates there's something more than metadata changes:

$ diff <(ar tv GOOD-libtclstub.a) <(ar tv BAD-libtclstub.a)
1,5c1,5
< rw-r--r-- 0/0 215296 Jul  8 00:00 2025 tclStubLib.o
< rw-r--r-- 0/0  31568 Jul  8 00:00 2025 tclStubCall.o
< rw-r--r-- 0/0 180832 Jul  8 00:00 2025 tclStubLibTbl.o
< rw-r--r-- 0/0 196392 Jul  8 00:00 2025 tclTomMathStubLib.o
< rw-r--r-- 0/0 208688 Jul  8 00:00 2025 tclOOStubLib.o
---
> rw-r--r-- 0/0 215256 Jul  8 00:00 2025 tclStubLib.o
> rw-r--r-- 0/0  31528 Jul  8 00:00 2025 tclStubCall.o
> rw-r--r-- 0/0 180792 Jul  8 00:00 2025 tclStubLibTbl.o
> rw-r--r-- 0/0 196336 Jul  8 00:00 2025 tclTomMathStubLib.o
> rw-r--r-- 0/0 208648 Jul  8 00:00 2025 tclOOStubLib.o

I reproduced this problem in a container, details here: https://sourceware.org/bugzilla/show_bug.cgi?id=33723#c11 Also, from the reproducer container, I exctracted two 'libtclstub.a' files (a good and a bad one): I got the "good" one from here (before applying add-determinism): ``` $ file /root/rpmbuild/BUILD/tcl-9.0.2-build/tcl9.0.2/unix/*.a /root/rpmbuild/BUILD/tcl-9.0.2-build/tcl9.0.2/unix/libtclstub.a: current ar archive ``` This is the bad one (after applying add-determinism): ``` $ file /root/rpmbuild/BUILD/tcl-9.0.2-build/BUILDROOT/usr/lib64/*.a /root/rpmbuild/BUILD/tcl-9.0.2-build/BUILDROOT/usr/lib64/libtclstub.a: current ar archive ``` I ran a `diff` with a couple of commands (`xxd` and `ar`): ``` $ diff -u <(xxd -a GOOD-libtclstub.a) <(xxd -a BAD-libtclstub.a) --- /dev/fd/63 2026-01-12 12:16:42.798422879 +0000 +++ /dev/fd/62 2026-01-12 12:16:42.798422879 +0000 @@ -1,11 +1,11 @@ 00000000: 213c 6172 6368 3e0a 2f20 2020 2020 2020 !<arch>./ -00000010: 2020 2020 2020 2020 3137 3637 3937 3137 17679717 -00000020: 3238 2020 3020 2020 2020 3020 2020 2020 28 0 0 +00000010: 2020 2020 2020 2020 3137 3531 3933 3238 17519328 +00000020: 3030 2020 3020 2020 2020 3020 2020 2020 00 0 0 00000030: 3020 2020 2020 2020 3239 3420 2020 2020 0 294 00000040: 2020 600a 0000 000e 0000 01bc 0000 01bc `............. 00000050: 0000 01bc 0000 01bc 0000 01bc 0000 01bc ................ -00000060: 0003 4af8 0003 4af8 0003 c684 0006 8920 ..J...J........ -00000070: 0006 8920 0009 8884 0009 8884 0009 8884 ... ............ +00000060: 0003 4ad0 0003 4ad0 0003 c634 0006 88a8 ..J...J....4.... +00000070: 0006 88a8 0009 87d4 0009 87d4 0009 87d4 ................ 00000080: 5463 6c5f 496e 6974 5374 7562 7300 7463 Tcl_InitStubs.tc 00000090: 6c53 7475 6273 4861 6e64 6c65 0074 636c lStubsHandle.tcl 000000a0: 496e 7450 6c61 7453 7475 6273 5074 7200 IntPlatStubsPtr. @@ -29,10 +29,10 @@ 000001c0: 7475 624c 6962 2e6f 2f20 2020 3137 3531 tubLib.o/ 1751 000001d0: 3933 3238 3030 2020 3020 2020 2020 3020 932800 0 0 000001e0: 2020 2020 3130 3036 3434 2020 3231 3532 100644 2152 -000001f0: 3936 2020 2020 600a 7f45 4c46 0201 0100 96 `..ELF.... +000001f0: 3536 2020 2020 600a 7f45 4c46 0201 0100 56 `..ELF.... 00000200: 0000 0000 0000 0000 0100 f300 0100 0000 ................ 00000210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ -00000220: 0042 0300 0000 0000 0500 0000 4000 0000 .B..........@... +00000220: d841 0300 0000 0000 0500 0000 4000 0000 .A..........@... 00000230: 0000 4000 1c00 1b00 5971 a2f0 a6ec 8018 ..@.....Yq...... 00000240: 86f4 4168 1308 08f0 9704 0000 83b4 0400 ..Ah............ 00000250: 0567 b287 3378 0601 2330 04fc 9060 233c .g..3x..#0...`#< ``` And the diff with `ar` indicates there's something more than metadata changes: ``` $ diff <(ar tv GOOD-libtclstub.a) <(ar tv BAD-libtclstub.a) 1,5c1,5 < rw-r--r-- 0/0 215296 Jul 8 00:00 2025 tclStubLib.o < rw-r--r-- 0/0 31568 Jul 8 00:00 2025 tclStubCall.o < rw-r--r-- 0/0 180832 Jul 8 00:00 2025 tclStubLibTbl.o < rw-r--r-- 0/0 196392 Jul 8 00:00 2025 tclTomMathStubLib.o < rw-r--r-- 0/0 208688 Jul 8 00:00 2025 tclOOStubLib.o --- > rw-r--r-- 0/0 215256 Jul 8 00:00 2025 tclStubLib.o > rw-r--r-- 0/0 31528 Jul 8 00:00 2025 tclStubCall.o > rw-r--r-- 0/0 180792 Jul 8 00:00 2025 tclStubLibTbl.o > rw-r--r-- 0/0 196336 Jul 8 00:00 2025 tclTomMathStubLib.o > rw-r--r-- 0/0 208648 Jul 8 00:00 2025 tclOOStubLib.o ```

kashyapc changed title from ~~[F43 rebuild] Some package builds fail when 'debugedit' cannot read debug sections~~ to Some package builds fail due to 'debugedit' can't read debug sections

2026-01-13 16:25:11 +00:00

kashyapc changed title from ~~Some package builds fail due to 'debugedit' can't read debug sections~~ to Some package builds fail because 'debugedit' cannot read debug sections

2026-01-13 21:07:30 +00:00

kashyapc commented

2026-01-15 11:51:41 +00:00

Author

Owner

A quick update. Some upstream progress:

This is also now being tracked here and is actively being looked into by Mark Weilaard: https://sourceware.org/bugzilla/show_bug.cgi?id=33789 (debugedit corrupts RISC-V object files).
Nick Clifton posted a patch to the binutils mailing list, that can also help potentially workaround the issue (assuming the patch is accepted): https://sourceware.org/pipermail/binutils/2026-January/147334.html

A quick update. Some upstream progress: - This is also now being tracked here and is actively being looked into by Mark Weilaard: https://sourceware.org/bugzilla/show_bug.cgi?id=33789 (debugedit corrupts RISC-V object files). - Nick Clifton posted a patch to the binutils mailing list, that can also help potentially workaround the issue (assuming the patch is accepted): https://sourceware.org/pipermail/binutils/2026-January/147334.html

kashyapc commented

2026-01-23 13:03:21 +00:00

Author

Owner

Relaying update from David from the upstream bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33789#c14

We landed debugedit-5.2-4.0.riscv64.fc43 with RFC patchset + performance improvement for Rawhide (dd changes, not related to this issue) yesterday.

The build: https://riscv-koji.fedoraproject.org/koji/buildinfo?buildID=60319

We have rebuilt successfully <30 packages so far, most of them affected by tcl and sysprof static libraries.

Relaying update from David from the upstream bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33789#c14 ``` We landed debugedit-5.2-4.0.riscv64.fc43 with RFC patchset + performance improvement for Rawhide (dd changes, not related to this issue) yesterday. The build: https://riscv-koji.fedoraproject.org/koji/buildinfo?buildID=60319 We have rebuilt successfully <30 packages so far, most of them affected by tcl and sysprof static libraries.

kashyapc commented

2026-02-03 13:02:58 +00:00

Author

Owner

@kashyapc wrote in #1 (comment):

Relaying update from David from the upstream bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33789#c14
We landed debugedit-5.2-4.0.riscv64.fc43 with RFC patchset + performance improvement for Rawhide (dd changes, not related to this issue) yesterday.

The build: https://riscv-koji.fedoraproject.org/koji/buildinfo?buildID=60319

Based on this, we're closing this issue.

Thanks to everyone that helped with this!

@kashyapc wrote in https://forge.fedoraproject.org/riscv/planning/issues/1#issuecomment-343707: > Relaying update from David from the upstream bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33789#c14 > > ```text > We landed debugedit-5.2-4.0.riscv64.fc43 with RFC patchset + performance improvement for Rawhide (dd changes, not related to this issue) yesterday. > > The build: https://riscv-koji.fedoraproject.org/koji/buildinfo?buildID=60319 Based on this, we're closing this issue. Thanks to everyone that helped with this!

kashyapc closed this issue

2026-02-03 13:02:58 +00:00

Rows
Columns

Some package builds fail because 'debugedit' cannot read debug sections #1

Description