Re: [sw-dev] Digest for sw-dev@groups.riscv.org - 1 update in 1 topic

[Robert Lipe]

Was this before or after the ABI changed? (I no longer follow the daily activities of GCC.)
https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4 was the announcement to this list, but didn't generate any discussion here.

If the change is from 11.2 to 11.3, I'd trust not, but RISC-V may still be young enough that compatibility across minor versions isn't guaranteed.

My read of that announcement is that mixing objects (.o, .so, .a) before and after that change may be awkward and that we should all eventually just embrace using the new flags and rebuilding. Fortunately, code using CSR[RW] and IFENCE is mostly in the system space where "recompile everything all from the same command" is the norm and most user-facing code won't be so much affected.

Still, as that change gets closer to landing in the mainstream, it's something we should all have on our radar. 

RJL

P.S. I think that MOST RISC-V consumers (builders of software, not end-users) are downstream of the awesome curated version at riscv-collab so that's probably the gate for most of us.

On Sat, May 14, 2022 at 8:25 PM <sw-...@groups.riscv.org> wrote:

sw-...@groups.riscv.org

Google Groups

Topic digest
View all topics

• xPack GNU RISC-V Embedded GCC v11.3.0-1 released - 1 Update

xPack GNU RISC-V Embedded GCC v11.3.0-1 released

Liviu Ionescu <i...@livius.net>: May 14 12:39AM -0700 Version 11.3.0-1 is a new release of the xPack GNU RISC-V Embedded GCC; it follows the GNU GCC release.   https://xpack.github.io/blog/2022/05/14/riscv-none-elf-gcc-v11-3-0-1-released/

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to sw-dev+un...@groups.riscv.org.

[Liviu Ionescu]

I'm not sure I understand your question, but if it is related to the `*_zicsr` change in the architecture strings, the ones accepted by 11.3 include this suffix, see the multi-libs listed in the release page.

The major change with this new release is that it no longer uses the SiFive vendor specific sources, but the official GNU sources.

Liviu

[Palmer Dabbelt]

On Sat, 14 May 2022 19:33:14 PDT (-0700), i...@livius.net wrote:
> I'm not sure I understand your question, but if it is related to the
> `*_zicsr` change in the architecture strings, the ones accepted by 11.3
> include this suffix, see the multi-libs listed in the release page.

We made a bunch of ISA string parsing updates over the last few months,
quite a few of which were backported to 11. We didn't change the
default ISA spec version, though, which is what Kito's post was
discussing. The ISA spec change is in GCC 12, as per the release notes.

You can double check to see where the "default" lives in the
with-isa-spec bit in config.gcc, the change landed in trunk as
98416dbb0a6 ("RISC-V: Change default ISA version into 20191213").
Changing that default (or picking a different one at configure-time)
will be visible to users, as the ISA string definitions changed between
2.2 and 20191213.

> The major change with this new release is that it no longer uses the SiFive
> vendor specific sources, but the official GNU sources.
>
> Liviu
>
> On Sunday, 15 May 2022 at 05:18:46 UTC+3 rober...@gmail.com wrote:
>
>>
>> Was this before or after the ABI changed? (I no longer follow the daily
>> activities of GCC.)
>> https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4 was
>> the announcement to this list, but didn't generate any discussion here.

That's not an ABI break (sort of, see later), it's just a change to the
default ISA version in GCC and binutils. It does break a lot of build
scripts, but not binaries.

>> If the change is from 11.2 to 11.3, I'd trust not, but RISC-V may still be
>> young enough that compatibility across minor versions isn't guaranteed.
>>
>> My read of that announcement is that mixing objects (.o, .so, .a) before
>> and after that change may be awkward and that we should all eventually just
>> embrace using the new flags and rebuilding. Fortunately, code using CSR[RW]
>> and IFENCE is mostly in the system space where "recompile everything all
>> from the same command" is the norm and most user-facing code won't be so
>> much affected.

You don't need to rebuild your code on any GCC/binutils update, we
follow the same ABI compatibility rules for the RISC-V port that every
other port does. Incompatibilities between binaries generated by GCC
upgrades, even major version upgrades, would be considered a bug.
That's not to say those bugs never happen (I personally rebuild my whole
system on GCC upgrades, even for my Intel boxes) but we certainly don't
break the ABI on purpose -- and if anything, given how much of a
headache ABI-breaking bugs are we're extra careful to avoid them.

In this specific case it turns out that, due to a bug in binutils,
objects that were perfectly compatible ended up being rejected. That
bug was fixed before the 2.38 release, users that run into it should
upgrade. Technically this could be considered an ABI break, as it means
that old binaries stopped working when mixed with new ones. New GCC
versions frequently discover bugs in old binutils (which is why upgrades
are required), but in this specific case older versions of GCC can be
made to trigger the same bug in binutils so it's a bit messier. There's
sort of a grey area here between what's an ABI-breaking option and
what's just a bug.

The bug in question just results in the linker throwing an error about
objects being incompatible when they're actually compatible, though, so
it's not all that scary as far as ABI bugs go. If you code links you're
safe, or at least safe from this bug.

>> Still, as that change gets closer to landing in the mainstream, it's
>> something we should all have on our radar.

Not sure what "mainstream" means here, but all these changes are
upstream. GCC 12 just released with the default ISA string change, but
it usually takes a while for distributions to do a major GCC version
upgrade -- looks like it's in Debian experimental but not yet unstable,
for example.

>>
>> RJL
>>
>> P.S. I think that MOST RISC-V consumers (builders of software, not
>> end-users) are downstream of the awesome curated version at riscv-collab so
>> that's probably the gate for most of us.

I'd suggest most toolchain distributors to use the official upstream
releases, that's been true for a while now. There are sometimes extra
RISC-V related backports in the RVI forks, but they're there because
they don't meet the standard backport rules and toolchain vendors should
thus consider them carefully -- not that they're wrong, just that they
may be unexpected.

>>
>> On Sat, May 14, 2022 at 8:25 PM <sw-...@groups.riscv.org> wrote:

z>>
>>> sw-...@groups.riscv.org
>>> <https://groups.google.com/a/groups.riscv.org/forum/?utm_source=digest&utm_medium=email#!forum/sw-dev/topics> Google
>>> Groups
>>> <https://groups.google.com/a/groups.riscv.org/forum/?utm_source=digest&utm_medium=email/#!overview>
>>> <https://groups.google.com/a/groups.riscv.org/forum/?utm_source=digest&utm_medium=email/#!overview>

>>> Topic digest
>>> View all topics

>>> <https://groups.google.com/a/groups.riscv.org/forum/?utm_source=digest&utm_medium=email#!forum/sw-dev/topics>
>>>
>>> - xPack GNU RISC-V Embedded GCC v11.3.0-1 released
>>> <#m_2244864126665464098_m_-7087438647260056312_group_thread_0> - 1

>>> Update
>>>
>>> xPack GNU RISC-V Embedded GCC v11.3.0-1 released

>>> <http://groups.google.com/a/groups.riscv.org/group/sw-dev/t/3264d9c80679c6e6?utm_source=digest&utm_medium=email>

>>> Liviu Ionescu <i...@livius.net>: May 14 12:39AM -0700
>>>
>>> Version 11.3.0-1 is a new release of the xPack GNU RISC-V Embedded GCC;
>>> it
>>> follows the GNU GCC release.
>>>
>>>
>>> https://xpack.github.io/blog/2022/05/14/riscv-none-elf-gcc-v11-3-0-1-released/

>>> Back to top <#m_2244864126665464098_m_-7087438647260056312_digest_top>

>>> You received this digest because you're subscribed to updates for this
>>> group. You can change your settings on the group membership page

>>> <https://groups.google.com/a/groups.riscv.org/forum/?utm_source=digest&utm_medium=email#!forum/sw-dev/join>
>>> .

[Jim Wilson]

On Sat, May 14, 2022 at 7:18 PM Robert Lipe <rober...@gmail.com> wrote:

Was this before or after the ABI changed? (I no longer follow the daily activities of GCC.)
https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4 was the announcement to this list, but didn't generate any discussion here.

It wasn't an ABI change.  It was a -march change.  It was the hardware guys that broke -march by making a non-backward compatible change to what "I" means in an arch string.  Our attempts to update gcc to use the new definition of "I" caused some minor problems but we should have them fixed by now.

Incidentally, the hardware guys are breaking -march again by making yet another non-backward compatible change to what "I" means.  A change was added in October that removes the rd* instructions from I base.  Also the hpm csrs, but probably few people use them.  The rd* instructions are commonly used in embedded code.  We will have more compiler breakage when we implement this change.  We have been discussing how best to deal with that.

Jim

 

[Liviu Ionescu]

> On 15 May 2022, at 19:44, Jim Wilson <jim.wil...@gmail.com> wrote:
>
> ... We have been discussing how best to deal with that.

Perhaps you can also discuss how to address the combinatorial growth of multilibs, since now a generic bare-metal toolchain is almost unmanageable, the archive is more than 400 MB, about twice the size of the Arm toolchain.

Liviu

[Jim Wilson]

On Sun, May 15, 2022 at 10:18 AM Liviu Ionescu <i...@livius.net> wrote:

Perhaps you can also discuss how to address the combinatorial growth of multilibs, since now a generic bare-metal toolchain is almost unmanageable, the archive is more than 400 MB, about twice the size of the Arm toolchain.

There is no good solution for that.  The number of extensions will continue to increase, which means there will be many more possible multilibs.  I think we are already in the millions.  The platforms/profiles work should help.  If we can get people to standardize on certain sets of combinations, then we don't need to build all possible combinations, just the standard ones.  Another proposed solution is to make it possible for people to build multilibs on demand instead of prebuilding them, but that would be a major project, and not clear if it is even possible.

Jim

[Liviu Ionescu]

> On 15 May 2022, at 20:33, Jim Wilson <jim.wil...@gmail.com> wrote:
>
> The number of extensions will continue to increase, which means there will be many more possible multilibs.

Contrary to the opinion of the hardware guys, I think that this is a serious flaw of the design.


Liviu

[Robert Lipe]

Thank you for the excellent explanations, Palmer and Jim. That's really helpful. I now better understand what changed.

As to Jim's point on multilib combinations, he's doubtlessly right that this is about to get MUCH worse for anyone trying to maintain a toolchain used on more than one chip.  

Thanx, gang, for all that you do.
RJL