qemu and glibc update committed to riscv-gnu-toolchain

[Jim Wilson]

I just committed a pull request for riscv-gnu-toolchain that upgrades
from the pre-release 2.26 glibc to upstream 2.29 glibc with Zong Li's
rv32 patch, upgrades to linux 5.0 kernel headers from a Kito Cheng
commit, and upgrades from riscv-qemu to upstream qemu. This is
possible now because some patches I wrote to fix problems with the
rv32 linux user support landed in upstream qemu. This is a pretty
major change, but primarily effects the linux support.

I created a branch before-upstream-qemu in case someone needs a copy
of riscv-gnu-toolchain before this change.

Jim

[Jorg Brown]

Thanks Jim.

Just nailing down some details...

The commit corresponding to this message is https://github.com/riscv/riscv-gnu-toolchain/commit/12b6dc81b7e7fe46a1987ffc6dbd710bcfaaf671#diff-a20dedb30539358f1a8a2f15f476f649 , right?

The commit description reads: "Use upstream glibc with Zong Li's rv32 patches."  and riscv-glibc says "Submodule riscv-glibc updated from 2f626d to 06983f".

I naively thought "riscv-glibc" would refer to https://github.com/riscv/riscv-glibc , and when I went there, the latest commit was shown as 06983fe, which is fine except that it was committed back on Jan 31, 2019.  That was also the release date of gcc 2.29.

Am I correct in thinking that the current riscv-compatible glibc is based on 2.29, and hasn't been updated since 2.29 went final on the same day?  (This isn't necessarily bad; it's just surprising, and since I'm usually wrong when something surprises me, I wanted to check and be sure.)

= - = - =

My context: I'm working on some library code, that currently supports multiple architectures, and trying to work out what version of Linux headers / glibc version / etc we should base everything on.

Is there any particular reason that glibc mainline won't accept the rv32 patches?

-- Jorg

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAFyWVabskvgv7_4LaqDposCHC%2BP0guASo_yUfxVrrz%3D4e3WWGw%40mail.gmail.com.

[Jim Wilson]

On Wed, Aug 21, 2019 at 8:12 PM Jorg Brown <jorg....@gmail.com> wrote:
> Am I correct in thinking that the current riscv-compatible glibc is based on 2.29, and hasn't been updated since 2.29 went final on the same day? (This isn't necessarily bad; it's just surprising, and since I'm usually wrong when something surprises me, I wanted to check and be sure.)

Correct. There is no one maintaining riscv/riscv-glibc, so updates
are rare. Long term we should probably just kill it and use upstream
instead, but we need the rv32 support to be upstreamed first. Long
term, I think all of the riscv/riscv-* toolchain stuff should be
killed in favor of the official upstream trees, except maybe keep
riscv/riscv-gnu-toolchain as a convenient build script.

> Is there any particular reason that glibc mainline won't accept the rv32 patches?

The rv32 support was deliberately withheld to avoid an inconvenient
ABI change shortly after upstreaming them. The 32-bit linux kernel
clock will overflow in 2038, requiring that the 32-bit clock be
replaced with a 64-bit one, which will require ABI breaking changes
for all 32-bit targets. This is called the y2038 problem. Since rv32
is new, we were hoping that the linux kernel y2038 fix would go in
first, before the rv32 glibc patches, so that we would use the new ABI
from the beginning. The linux kernel fixes took longer than expected.

Also, the rv32 glibc patches have been in dire need of a volunteer to
work on them. Andes wrote the patches, but Andes doesn't like to
upstream, and effectively ended up abandoning them. Then it was 6-9
months before someone else volunteered to pick up the work. It is now
being done by Alistair Francis at Western Digital. What he discovered
was that the linux kernel y2038 caused more problems than expected, as
some 32-bit linux syscalls were dropped, and it turns out that glibc
in some cases has no support for calling the 64-bit version when the
32-bit version is missing for a 32-bit target. So glibc needed some
unexpected infrastructure work to be compatible with the y2038 linux
kernel patches. That stuff is still being written. If you look at
libc-alpha you will see Alistair's patch sets. He is making progress,
though I don't know how much more work is required to finish this.

Note that the rv32 ABI won't be finalized until the patches are
accepted upstream, so it isn't safe to assume that anything done now
will still work after glibc is accepted upstream. In particularly,
the current stuff using Zong Li's patch and glibc-2.29 is pre-y2038
linux kernel patches, so is definitely using a different ABI than what
we will have when the work is finished.

Jim