I'm not sure exactly the effect on RISC-V binaries, but I wanted to raise it here to get the attention of the Fedora toolchain team ...
Here's the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31179 RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
It refers to this change in binutils 2.41:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
As far as I understand the issue (which is not too far) this mainly affects shipped *.o and *.a files (ie. static libraries and similar) which were compiled with binutils < 2.41, which either won't link correctly or will give a linker error when using GNU ld from binutils 2.41.
Unclear if it also affects *.so files (which would be a much more serious ABI break), and also if it affects most binaries or just a few. I initially thought this only affected programs using 128 bit ints, so didn't think it was too important, but after reading the commit I'm not sure that is really true.
There's been discussion about adding an ELF tag, but that seems very problematic to me: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/414
Rich.
On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones rjones@redhat.com wrote:
I'm not sure exactly the effect on RISC-V binaries, but I wanted to raise it here to get the attention of the Fedora toolchain team ...
Here's the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31179 RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
It refers to this change in binutils 2.41:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
As far as I understand the issue (which is not too far) this mainly affects shipped *.o and *.a files (ie. static libraries and similar) which were compiled with binutils < 2.41, which either won't link correctly or will give a linker error when using GNU ld from binutils 2.41.
Correction. This is broken in <= 2.41 (incl. the current stable binutils release).
Unclear if it also affects *.so files (which would be a much more serious ABI break), and also if it affects most binaries or just a few. I initially thought this only affected programs using 128 bit ints, so didn't think it was too important, but after reading the commit I'm not sure that is really true.
Nelson Chu committed (5 days ago) a change:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
This will accept whatever is produced by <= 2.41 and the final binary will be correct. There is also a new ld flag (--check-uleb128) which can produce a warning if it detects an issue.
I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen before I start mass rebuilding, and that should fix this.
There's been discussion about adding an ELF tag, but that seems very problematic to me: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/414
Yeah. I doubt we need a tag. I don't think it solves anything. Nelson commit (i.e. workaround) + mass rebuild should resolve any inconveniences AFAIK.
Cheers, david
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
* David Abdurachmanov:
On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones rjones@redhat.com wrote:
I'm not sure exactly the effect on RISC-V binaries, but I wanted to raise it here to get the attention of the Fedora toolchain team ...
Here's the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31179 RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
It refers to this change in binutils 2.41:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
As far as I understand the issue (which is not too far) this mainly affects shipped *.o and *.a files (ie. static libraries and similar) which were compiled with binutils < 2.41, which either won't link correctly or will give a linker error when using GNU ld from binutils 2.41.
Correction. This is broken in <= 2.41 (incl. the current stable binutils release).
Unclear if it also affects *.so files (which would be a much more serious ABI break), and also if it affects most binaries or just a few. I initially thought this only affected programs using 128 bit ints, so didn't think it was too important, but after reading the commit I'm not sure that is really true.
Nelson Chu committed (5 days ago) a change:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
This will accept whatever is produced by <= 2.41 and the final binary will be correct. There is also a new ld flag (--check-uleb128) which can produce a warning if it detects an issue.
I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen before I start mass rebuilding, and that should fix this.
Cc:ing Nick and Siddhesh for awareness.
The current plan is to use binutils 2.41 for the mass rebuild.
Thanks, Florian
On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer fweimer@redhat.com wrote:
- David Abdurachmanov:
On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones rjones@redhat.com wrote:
I'm not sure exactly the effect on RISC-V binaries, but I wanted to raise it here to get the attention of the Fedora toolchain team ...
Here's the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31179 RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
It refers to this change in binutils 2.41:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
As far as I understand the issue (which is not too far) this mainly affects shipped *.o and *.a files (ie. static libraries and similar) which were compiled with binutils < 2.41, which either won't link correctly or will give a linker error when using GNU ld from binutils 2.41.
Correction. This is broken in <= 2.41 (incl. the current stable binutils release).
Unclear if it also affects *.so files (which would be a much more serious ABI break), and also if it affects most binaries or just a few. I initially thought this only affected programs using 128 bit ints, so didn't think it was too important, but after reading the commit I'm not sure that is really true.
Nelson Chu committed (5 days ago) a change:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
This will accept whatever is produced by <= 2.41 and the final binary will be correct. There is also a new ld flag (--check-uleb128) which can produce a warning if it detects an issue.
I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen before I start mass rebuilding, and that should fix this.
Cc:ing Nick and Siddhesh for awareness.
The current plan is to use binutils 2.41 for the mass rebuild.
In Fedora/RISCV we typically end up using the latest available binutils. We are slightly different from upstream/normal Fedora.
Cheers, david
Thanks, Florian
On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer fweimer@redhat.com wrote:
- David Abdurachmanov:
On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones rjones@redhat.com wrote:
I'm not sure exactly the effect on RISC-V binaries, but I wanted to raise it here to get the attention of the Fedora toolchain team ...
Here's the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31179 RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
It refers to this change in binutils 2.41:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
As far as I understand the issue (which is not too far) this mainly affects shipped *.o and *.a files (ie. static libraries and similar) which were compiled with binutils < 2.41, which either won't link correctly or will give a linker error when using GNU ld from binutils 2.41.
Correction. This is broken in <= 2.41 (incl. the current stable binutils release).
Unclear if it also affects *.so files (which would be a much more serious ABI break), and also if it affects most binaries or just a few. I initially thought this only affected programs using 128 bit ints, so didn't think it was too important, but after reading the commit I'm not sure that is really true.
Nelson Chu committed (5 days ago) a change:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
This will accept whatever is produced by <= 2.41 and the final binary will be correct. There is also a new ld flag (--check-uleb128) which can produce a warning if it detects an issue.
I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen before I start mass rebuilding, and that should fix this.
Cc:ing Nick and Siddhesh for awareness.
The current plan is to use binutils 2.41 for the mass rebuild.
In Fedora/RISCV we typically end up using the latest available binutils. We are slightly different from upstream/normal Fedora.
Which is fine when you're an out of mainline architecture but these sorts of things need to be resolved well and truly before any incorporation can happen.
On Tue, Jan 2, 2024 at 6:26 PM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer fweimer@redhat.com wrote:
- David Abdurachmanov:
On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones rjones@redhat.com wrote:
I'm not sure exactly the effect on RISC-V binaries, but I wanted to raise it here to get the attention of the Fedora toolchain team ...
Here's the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31179 RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
It refers to this change in binutils 2.41:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
As far as I understand the issue (which is not too far) this mainly affects shipped *.o and *.a files (ie. static libraries and similar) which were compiled with binutils < 2.41, which either won't link correctly or will give a linker error when using GNU ld from binutils 2.41.
Correction. This is broken in <= 2.41 (incl. the current stable binutils release).
Unclear if it also affects *.so files (which would be a much more serious ABI break), and also if it affects most binaries or just a few. I initially thought this only affected programs using 128 bit ints, so didn't think it was too important, but after reading the commit I'm not sure that is really true.
Nelson Chu committed (5 days ago) a change:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
This will accept whatever is produced by <= 2.41 and the final binary will be correct. There is also a new ld flag (--check-uleb128) which can produce a warning if it detects an issue.
I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen before I start mass rebuilding, and that should fix this.
Cc:ing Nick and Siddhesh for awareness.
The current plan is to use binutils 2.41 for the mass rebuild.
In Fedora/RISCV we typically end up using the latest available binutils. We are slightly different from upstream/normal Fedora.
Which is fine when you're an out of mainline architecture but these sorts of things need to be resolved well and truly before any incorporation can happen.
100% true. We have plenty of stuff that isn't yet submitted to the official dist-git.
I have been considering not going for 2.42 for Fedora 40, but we will do this again one more time (hopefully it's the last time, but you never know).
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jan 2, 2024 at 5:15 PM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Tue, Jan 2, 2024 at 6:26 PM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer fweimer@redhat.com wrote:
- David Abdurachmanov:
On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones rjones@redhat.com wrote:
I'm not sure exactly the effect on RISC-V binaries, but I wanted to raise it here to get the attention of the Fedora toolchain team ...
Here's the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31179 RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
It refers to this change in binutils 2.41:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
As far as I understand the issue (which is not too far) this mainly affects shipped *.o and *.a files (ie. static libraries and similar) which were compiled with binutils < 2.41, which either won't link correctly or will give a linker error when using GNU ld from binutils 2.41.
Correction. This is broken in <= 2.41 (incl. the current stable binutils release).
Unclear if it also affects *.so files (which would be a much more serious ABI break), and also if it affects most binaries or just a few. I initially thought this only affected programs using 128 bit ints, so didn't think it was too important, but after reading the commit I'm not sure that is really true.
Nelson Chu committed (5 days ago) a change:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
This will accept whatever is produced by <= 2.41 and the final binary will be correct. There is also a new ld flag (--check-uleb128) which can produce a warning if it detects an issue.
I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen before I start mass rebuilding, and that should fix this.
Cc:ing Nick and Siddhesh for awareness.
The current plan is to use binutils 2.41 for the mass rebuild.
In Fedora/RISCV we typically end up using the latest available binutils. We are slightly different from upstream/normal Fedora.
Which is fine when you're an out of mainline architecture but these sorts of things need to be resolved well and truly before any incorporation can happen.
100% true. We have plenty of stuff that isn't yet submitted to the official dist-git.
Is that delta easily viewable somewhere?
I have been considering not going for 2.42 for Fedora 40, but we will do this again one more time (hopefully it's the last time, but you never know).
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jan 2, 2024 at 7:20 PM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jan 2, 2024 at 5:15 PM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Tue, Jan 2, 2024 at 6:26 PM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer fweimer@redhat.com wrote:
- David Abdurachmanov:
On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones rjones@redhat.com wrote: > > > I'm not sure exactly the effect on RISC-V binaries, but I wanted to > raise it here to get the attention of the Fedora toolchain team ... > > Here's the bug: > > https://sourceware.org/bugzilla/show_bug.cgi?id=31179 > RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects > > It refers to this change in binutils 2.41: > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7... > > As far as I understand the issue (which is not too far) this mainly > affects shipped *.o and *.a files (ie. static libraries and similar) > which were compiled with binutils < 2.41, which either won't link > correctly or will give a linker error when using GNU ld from binutils 2.41.
Correction. This is broken in <= 2.41 (incl. the current stable binutils release).
> > Unclear if it also affects *.so files (which would be a much more > serious ABI break), and also if it affects most binaries or just a > few. I initially thought this only affected programs using 128 bit > ints, so didn't think it was too important, but after reading the > commit I'm not sure that is really true.
Nelson Chu committed (5 days ago) a change:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
This will accept whatever is produced by <= 2.41 and the final binary will be correct. There is also a new ld flag (--check-uleb128) which can produce a warning if it detects an issue.
I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen before I start mass rebuilding, and that should fix this.
Cc:ing Nick and Siddhesh for awareness.
The current plan is to use binutils 2.41 for the mass rebuild.
In Fedora/RISCV we typically end up using the latest available binutils. We are slightly different from upstream/normal Fedora.
Which is fine when you're an out of mainline architecture but these sorts of things need to be resolved well and truly before any incorporation can happen.
100% true. We have plenty of stuff that isn't yet submitted to the official dist-git.
Is that delta easily viewable somewhere?
Kinda.
If you list all the builds for the f40 tag in Fedora/RISCV Koji, and then look for the .X.riscv64 pattern before %{?dist} you will get a list of packages that are modified in some way. Today that's around ~277 packages. A good portion of those are easy fixes (e.g. a lot of packages assume that valgrind is available on just any arch, and never check %{valgrind_arches}). Some of the changes are bigger, like full ports, that for one or another reason were not accepted upstream (yet).
Not all the changes are good to for a PR. Thus some definitely need some refinement to do the correct thing.
Then actual changes are here: http://fedora.riscv.rocks:3000/rpms/<pkg_name> Typically this should have a branch with "-riscv64" suffix, e.g., f38-riscv64 or main-riscv64.
I hope to reduce that to a minimum during Fedora 40, but I am not making any promises.
Cheers, david
I have been considering not going for 2.42 for Fedora 40, but we will do this again one more time (hopefully it's the last time, but you never know).
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi David, Hi Florian,
Here's the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31179 RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
It refers to this change in binutils 2.41:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
FYI, a second patch is also needed: "RISC-V: Clarify the behaviors of SET/ADD/SUB relocations." This is commit: 2029e13917d53d2289d3ebb390c4f40bd2112d21
In Fedora/RISCV we typically end up using the latest available binutils. We are slightly different from upstream/normal Fedora.
I have now backported both of the above commits to rawhide binutils. Build: binutils-2.31-18.fc40
Cheers Nick
On Thu, Jan 4, 2024 at 11:20 AM Nick Clifton nickc@redhat.com wrote:
Hi David, Hi Florian,
Here's the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31179 RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
It refers to this change in binutils 2.41:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d7...
FYI, a second patch is also needed: "RISC-V: Clarify the behaviors of SET/ADD/SUB relocations." This is commit: 2029e13917d53d2289d3ebb390c4f40bd2112d21
Yes. This one is the actual fix. The one mentioned above is a temporary workaround to accept older broken object files.
In Fedora/RISCV we typically end up using the latest available binutils. We are slightly different from upstream/normal Fedora.
I have now backported both of the above commits to rawhide binutils. Build: binutils-2.31-18.fc40
I saw you making some builds, and I had a guess that you are most likely working on it :)
binutils-2.31-18.fc40 didn't land in f40 as Bodhi CI gating marked it as failed. The failures don't seem to be related to binutils package itself. Seems like CI test is/was broken, or maybe a temporary network issue, or something else.
Cheers, david
Cheers Nick
Hi David,
binutils-2.31-18.fc40 didn't land in f40 as Bodhi CI gating marked it as failed. The failures don't seem to be related to binutils package itself. Seems like CI test is/was broken, or maybe a temporary network issue, or something else.
It looks like rpminspect does not like two of the licenses used by the binutils:
BAD Unapproved license in binutils-2.41-19.fc40.src: GPL-2.0-or-later LGPL-2.1-or-later
Which seems wrong to me, since they are listed in the allowed licenses list for Fedora. I'll ask David Cantrell about it.
Cheers Nick
On Thu, Jan 4, 2024 at 4:07 PM Nick Clifton nickc@redhat.com wrote:
Hi David,
binutils-2.31-18.fc40 didn't land in f40 as Bodhi CI gating marked it as failed. The failures don't seem to be related to binutils package itself. Seems like CI test is/was broken, or maybe a temporary network issue, or something else.
It looks like rpminspect does not like two of the licenses used by the binutils:
BAD Unapproved license in binutils-2.41-19.fc40.src: GPL-2.0-or-later LGPL-2.1-or-later
Which seems wrong to me, since they are listed in the allowed licenses list for Fedora. I'll ask David Cantrell about it.
I think this one was always failing. The one that probably causes the issue in Bodhi is: fedora-ci.koji-build.tier0.functional
There is already a comment for binutils-2.41-19.fc40 in Bodhi. Basically the existing test will fail due to wget -> wget2 change. It sounds like you need to ignore this failing test for now.
Cheers, david
Cheers Nick
-
David Abdurachmanov -
Florian Weimer -
Nick Clifton -
Peter Robinson -
Richard W.M. Jones