Fedora Account System
Red Hat Associate
Red Hat Customer
When trying to build the newest version of xdp-tools for rawhide, 'strip' fails with "unsupported relocation type 0x4" on all the BPF object files. Building the same SRPM for Fedora 38 works fine, so this seems to be a recent regression. Failing build (rawhide): https://koji.fedoraproject.org/koji/taskinfo?taskID=107829608 Working build (f38): https://koji.fedoraproject.org/koji/taskinfo?taskID=107830030 Examples of the error message being emitted: /usr/bin/strip: BFD version 2.41-8.fc40 assertion fail ../../bfd/elf64-bpf.c:67 /usr/bin/strip: /builddir/build/BUILDROOT/xdp-tools-1.4.1-1.fc40.aarch64/usr/lib64/bpf/xdp-dispatcher.o: unsupported relocation type 0x4 /usr/bin/strip: /builddir/build/BUILDROOT/xdp-tools-1.4.1-1.fc40.aarch64/usr/lib64/bpf/xdp-dispatcher.o: bad value Reproducible: Always
May you please attach the object files in question to this issue so we can review them? Relocation type 0x4 is R_BPF_64_NODYLD32. /* R_BPF_64_NODYLD32 is not used by GNU tools. * It is kept in this file to remind that the value is already taken. */ RELOC_NUMBER (R_BPF_64_NODYLD32, 4) Has this relocation always been present in the object file from the old and new builds? Is the regression that binutils is being too strict and should go back to ignoring this? The Runtime Dyanmic loader engine in llvm just ignores this relocation and does nothing, it seems only useful to mark these symbols for lld section merging.
Created attachment 1995567 [details] xdp-dispatcher.o object file, as compiled on f38 The relocation type was added to LLVM back in 2021, so it doesn't seem to be a new thing: https://github.com/llvm/llvm-project/commit/6a2ea84600ba4bd3b2733bd8f08f5115eb32164b Generally, BPF relocations are processed by libbpf at load time, so I think the right thing to do here is to just ignore them. I'm attaching the xdp-dispatcher.o file as compiled on f38. My Rawhide install seems to have broken, so can't provide a rawhide version right now. Let me know if this one is not enough, though, and I'll try to get it re-enabled.
(In reply to Toke Høiland-Jørgensen from comment #3) > Created attachment 1995567 [details] > xdp-dispatcher.o object file, as compiled on f38 > > The relocation type was added to LLVM back in 2021, so it doesn't seem to be > a new thing: > https://github.com/llvm/llvm-project/commit/ > 6a2ea84600ba4bd3b2733bd8f08f5115eb32164b > > Generally, BPF relocations are processed by libbpf at load time, so I think > the right thing to do here is to just ignore them. ELF does not allow ignoring relocations in relocatable (ET_REL) object files in general. Each tool rewriting such object files needs to be taught about all the relocations and which ones do not require special processing (so that they can be copied over unchanged into the output).
Right, okay, s/ignore/copy as-is/ - or whatever it is that older versions of binutils was doing :)
(In reply to Florian Weimer from comment #4) > (In reply to Toke Høiland-Jørgensen from comment #3) > > Created attachment 1995567 [details] > > xdp-dispatcher.o object file, as compiled on f38 > > > > The relocation type was added to LLVM back in 2021, so it doesn't seem to be > > a new thing: > > https://github.com/llvm/llvm-project/commit/ > > 6a2ea84600ba4bd3b2733bd8f08f5115eb32164b > > > > Generally, BPF relocations are processed by libbpf at load time, so I think > > the right thing to do here is to just ignore them. > > ELF does not allow ignoring relocations in relocatable (ET_REL) object files > in general. Each tool rewriting such object files needs to be taught about > all the relocations and which ones do not require special processing (so > that they can be copied over unchanged into the output). Upstream development binutils seems to handle R_BPF_64_NODYLD32 correctly. e.g. Relocation section '.rel.BTF' at offset 0x3660 contains 3 entries: Offset Info Type Symbol's Value Symbol's Name 000000000000038c 0000001100000003 R_BPF_64_ABS32 0000000000000000 .rodata 00000000000003a4 0000002500000004 R_BPF_64_NODYLD32 0000000000000000 _license 00000000000003bc 0000002600000004 R_BPF_64_NODYLD32 0000000000000000 dispatcher_version Relocation section '.rel.BTF.ext' at offset 0x3690 contains 134 entries: Offset Info Type Symbol's Value Symbol's Name 000000000000002c 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text ... $ ./binutils/strip-new ~/Downloads/xdp-dispatcher.f38.o -o ~/Downloads/xdp-dispatcher.strip.o [carlos@athas binutils]$ echo $? 0 binutils 2.41 release from binutils-2_41 tag also works though. And Fedora 40 binutils strip also works: ⬢[carlos@toolbox home]$ strip ~/Downloads/xdp-dispatcher.f38.o -o ~/Downloads/xdp-dispatcher.f40strip.o ⬢[carlos@toolbox home]$ strip --version GNU strip version 2.41-8.fc40 Copyright (C) 2023 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. We really need access to the fc40 built BFP object file.
Created attachment 1996138 [details] xdp-dispatcher.o object file, as compiled on rawhide Adding the object file as compiled on rawhide. When running objdump on it I get: RELOCATION RECORDS FOR [.BTF]:BFD: BFD version 2.41-8.fc40 assertion fail ../../bfd/elf64-bpf.c:67 BFD: lib/libxdp/xdp-dispatcher.o: unsupported relocation type 0x4 objdump: failed to read relocs in: lib/libxdp/xdp-dispatcher.o objdump: error message was: bad value RELOCATION RECORDS FOR [.BTF.ext]:BFD: BFD version 2.41-8.fc40 assertion fail ../../bfd/elf64-bpf.c:67 BFD: lib/libxdp/xdp-dispatcher.o: unsupported relocation type 0x4 objdump: failed to read relocs in: lib/libxdp/xdp-dispatcher.o objdump: error message was: bad value This is only on rawhide; the f38 objdump has no problems reading the file. I get identical errors when pointing objdump at the f38 version of the object file, BTW. However, 'strip' doesn't complain, so I guess the rpm build runs that with some other parameters? Anyway, manually running rpmbuild on rawhide also fails...
The change happened because of commit 5e4c7a839d1c which refactored the BPF relocation handling code. This was contributed by Oracle in March 2023: https://sourceware.org/pipermail/binutils/2023-March/126428.html Anyway, I can reproduce the problem, so I will create a patch to fix it.
(In reply to Carlos O'Donell from comment #6) > $ ./binutils/strip-new ~/Downloads/xdp-dispatcher.f38.o -o > ~/Downloads/xdp-dispatcher.strip.o > [carlos@athas binutils]$ echo $? > 0 Although not mentioned in the original bug report, you need to use strip to remove just the debug information in order to trigger this problem. ie: $ strip -g xdp-dispatcher.f38.o -o fred strip: BFD (GNU Binutils) 2.41.50.20231030 assertion fail bfd/elf64-bpf.c:67 strip: xdp-dispatcher.f38.o: unsupported relocation type 0x4 strip: xdp-dispatcher.f38.o: bad value $ echo $? 1
Fixed in binutils-2.41-9.fc40.
Awesome, thanks for taking care of this :)
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 40 entered end-of-life (EOL) status on 2025-05-13. Fedora Linux 40 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.