Mandating that pcrel_lo and pcrel_hi stay in the same section
74 views
Skip to first unread message
Palmer Dabbelt
Apr 16, 2019, 10:10:36 PM4/16/19
to sw-...@groups.riscv.org
There's a proposal out on the RISC-V ELF psABI specification's github repo that
is nominally an ABI change. The ABI is frozen, but we do make exceptions for
cases like this where we think this quirk is unlikely to be useful and causes
trouble for implementations. The full discussion can be seen here
https://github.com/riscv/riscv-elf-psabi-doc/issues/90
Since it's officially an ABI change I wanted to bring it up here to make sure
nobody was relying on it. Given that the quirk causes binutils to fail when
linking and was only found when trying to simplify LLD we think it's unlikely
that any objects taking advantage of this ABI quirk exist in the wild, which is
the only reason we're even considering the change in the first place.
The maintainers of the various RISC-V toolchains appear to be in agreement that
adding a restriction to the ABI is the right way to go, but I thought it would
be good to bring up here in case someone wasn't watching github.
is nominally an ABI change. The ABI is frozen, but we do make exceptions for
cases like this where we think this quirk is unlikely to be useful and causes
trouble for implementations. The full discussion can be seen here
https://github.com/riscv/riscv-elf-psabi-doc/issues/90
Since it's officially an ABI change I wanted to bring it up here to make sure
nobody was relying on it. Given that the quirk causes binutils to fail when
linking and was only found when trying to simplify LLD we think it's unlikely
that any objects taking advantage of this ABI quirk exist in the wild, which is
the only reason we're even considering the change in the first place.
The maintainers of the various RISC-V toolchains appear to be in agreement that
adding a restriction to the ABI is the right way to go, but I thought it would
be good to bring up here in case someone wasn't watching github.
Richard W.M. Jones
Apr 17, 2019, 5:13:33 PM4/17/19
to Palmer Dabbelt, David Abdurachmanov, sw-...@groups.riscv.org
understand :-( Is there a way we can test if any of our existing
binaries would be affected?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
Jim Wilson
Apr 17, 2019, 7:18:34 PM4/17/19
to Richard W.M. Jones, Palmer Dabbelt, David Abdurachmanov, RISC-V SW Dev
On Wed, Apr 17, 2019 at 2:13 PM Richard W.M. Jones <rjo...@redhat.com> wrote:
> This seems to be very deep in parts of the ABI which I don't
> understand :-( Is there a way we can test if any of our existing
> binaries would be affected?
Anything linked by GNU ld is not affected.
> This seems to be very deep in parts of the ABI which I don't
> understand :-( Is there a way we can test if any of our existing
> binaries would be affected?
Anything compiled by GCC is not affected unless you used
-fexplicit-relocs which is not the default and not recommended because
it it known to fail in some cases.
So you would have to have hand written assembly, or a file compiled by
gcc with a known unsafe optimization option, or maybe a file compiled
by LLVM, and then linked by LLD.
Jim
Richard W.M. Jones
Apr 18, 2019, 4:05:59 AM4/18/19
to Jim Wilson, Palmer Dabbelt, David Abdurachmanov, RISC-V SW Dev
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
Palmer Dabbelt
Apr 18, 2019, 2:46:04 PM4/18/19
to lk...@lkcl.net, sw-...@groups.riscv.org
On Wed, 17 Apr 2019 11:15:02 PDT (-0700), lk...@lkcl.net wrote:
> to have distros know and be able to plan. So, yes, heads up v important,
> thank you.
>
> Debian critically relies on frozen binutils for base stability of a given
> series (7, 8, 9 etc) and they do not permit upgrades to binutils because it
> requires basically total full upgrades, replacing literally all packages,
> on hundreds of thousands of live running machines, world wide.
>
> They will need to backport and even that is going to take some wrangling.
Sorry if I've misrepreseted the issue, but this doesn't require any action from
distributions based on binutils. We're suggesting removing a feature from the
ABI, but it's a feature that binutils has never supported (and would be tricky
to implement).
> Arch will sort-of be fine as they do rolling releases, users are used to
> having to do significant upgrades.
>
> Gentoo, and other source based distros.. don't care :)
I'm not a distro person, but as far as I understand it the rolling release
based distributions have much more trouble handling flag days. The versioned
distributions can at least batch these all up into the next version, which is
often times an ABI flag day anyway (as most packages don't bother with stable
ABIs).
If you're on a rolling release there's no pre-planned flag day to piggyback on,
so ABI changes tend to go less smoothly. From my limited experience ABI flag
days are way worse on the source-based distributions than the binary ones, as
with the binary distributions at least you can get away with keeping the old
ABI on the system while binaries for the new ABI are produced.
None of that is really relevant though, as we have no intention of ever
introducing an ABI change that would actually require distributions to trigger
global package rebuilds.
> I will ping debian riscv. Has anyone contacted Richard Jones of Fedora?
Appears he's already on the thread, but like I said above it's really not a
distribution issue. The question here is really "is restricting the ABI in
this fashion the right thing to do?" Right now it looks like this particular
ABI feature would be hard to support in binutils. Given that we can't find an
interesting use case for the feature it seems better to just change the spec to
match the implementation.
> On Wednesday, April 17, 2019, Palmer Dabbelt <pal...@sifive.com> wrote:
>
>> There's a proposal out on the RISC-V ELF psABI specification's github repo
>> that is nominally an ABI change. The ABI is frozen, but we do make
>> exceptions for cases like this where we think this quirk is unlikely to be
>> useful and causes trouble for implementations. The full discussion can be
>> seen here
>>
>> https://github.com/riscv/riscv-elf-psabi-doc/issues/90
>>
>> Since it's officially an ABI change I wanted to bring it up here to make
>> sure nobody was relying on it. Given that the quirk causes binutils to
>> fail when linking and was only found when trying to simplify LLD we think
>> it's unlikely that any objects taking advantage of this ABI quirk exist in
>> the wild, which is the only reason we're even considering the change in the
>> first place.
>>
>> The maintainers of the various RISC-V toolchains appear to be in agreement
>> that adding a restriction to the ABI is the right way to go, but I thought
>> it would be good to bring up here in case someone wasn't watching github.
>
> Thank you, Palmer, yes it has huge ramifications, so it is really important
>
>> There's a proposal out on the RISC-V ELF psABI specification's github repo
>> that is nominally an ABI change. The ABI is frozen, but we do make
>> exceptions for cases like this where we think this quirk is unlikely to be
>> useful and causes trouble for implementations. The full discussion can be
>> seen here
>>
>> https://github.com/riscv/riscv-elf-psabi-doc/issues/90
>>
>> Since it's officially an ABI change I wanted to bring it up here to make
>> sure nobody was relying on it. Given that the quirk causes binutils to
>> fail when linking and was only found when trying to simplify LLD we think
>> it's unlikely that any objects taking advantage of this ABI quirk exist in
>> the wild, which is the only reason we're even considering the change in the
>> first place.
>>
>> The maintainers of the various RISC-V toolchains appear to be in agreement
>> that adding a restriction to the ABI is the right way to go, but I thought
>> it would be good to bring up here in case someone wasn't watching github.
>
> to have distros know and be able to plan. So, yes, heads up v important,
> thank you.
>
> Debian critically relies on frozen binutils for base stability of a given
> series (7, 8, 9 etc) and they do not permit upgrades to binutils because it
> requires basically total full upgrades, replacing literally all packages,
> on hundreds of thousands of live running machines, world wide.
>
> They will need to backport and even that is going to take some wrangling.
Sorry if I've misrepreseted the issue, but this doesn't require any action from
distributions based on binutils. We're suggesting removing a feature from the
ABI, but it's a feature that binutils has never supported (and would be tricky
to implement).
> Arch will sort-of be fine as they do rolling releases, users are used to
> having to do significant upgrades.
>
> Gentoo, and other source based distros.. don't care :)
I'm not a distro person, but as far as I understand it the rolling release
based distributions have much more trouble handling flag days. The versioned
distributions can at least batch these all up into the next version, which is
often times an ABI flag day anyway (as most packages don't bother with stable
ABIs).
If you're on a rolling release there's no pre-planned flag day to piggyback on,
so ABI changes tend to go less smoothly. From my limited experience ABI flag
days are way worse on the source-based distributions than the binary ones, as
with the binary distributions at least you can get away with keeping the old
ABI on the system while binaries for the new ABI are produced.
None of that is really relevant though, as we have no intention of ever
introducing an ABI change that would actually require distributions to trigger
global package rebuilds.
> I will ping debian riscv. Has anyone contacted Richard Jones of Fedora?
Appears he's already on the thread, but like I said above it's really not a
distribution issue. The question here is really "is restricting the ABI in
this fashion the right thing to do?" Right now it looks like this particular
ABI feature would be hard to support in binutils. Given that we can't find an
interesting use case for the feature it seems better to just change the spec to
match the implementation.
Karsten Merker
Apr 20, 2019, 4:01:07 AM4/20/19
to Palmer Dabbelt, sw-...@groups.riscv.org
JFTR with my Debian hat on: if my understanding of the matter is correct,
making the priv spec stricter in this regard shouldn't affect Debian (or
any other existing RISC-V binary distribution), so no objection from
my side.
Regards,
Karsten
--
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.
Reply all
Reply to author
Forward
0 new messages