Re: Welcome to the list!
On Wed, Nov 09, 2016 at 11:53:05AM +0100, Paul van der Vlis wrote:
> Op 08-11-16 om 09:41 schreef Manuel A. Fernandez Montecelo:
> > But specially, as something still under heavy development, there is
> > the possibility of incompatible ABI changes that could render most of
> > the work so far useless. In fact, I heard of some worrying news in
> > that front, but don't know more details yet.
> >
> > I will hope to have more time as the end of the year comes closer and
> > review the situation. At the moment I have ~600 source packages built
> > (~2000 binary packages, I think) and mostly working so I've been
> > building many of these packages natively, although with the caveats
> > that changes in glibc and other basic libraries might render this
> > useless.
>
> Maybe they need to be build again, but I don't think the work will be
> useless.
>
> > Some key packages typically installed by debootstrap are still missing
> > due to circular dependencies, or still cross-compiled but not compiled
> > natively/cleanly.
>
> Maybe you can tell a bit about the major problems in the toolchain, and
> if somebody is allready working on it.
Regarding the "general" build toolchain:
- The RISC-V binutils codebase is in principle upstreamed since a
few days:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=e23eba971dd409b999dd83d8df0f842680c1c642
Nonetheless there are AFAIK still a number of points that need
adjustments and may break compatibility with (some) existing
binaries. AFAIK one thing that is still being discussed is the
correct format/value of certain ELF header data for RISC-V, but
I am not familiar with the specifics of ELF, so I don't know
any details.
- RISC-V code for gcc is AFAIK largely in a state that would
allow starting upstreaming, but that hasn't begun yet as the
legal paperwork for the copyright assignment on the gcc code
isn't yet ready, although this is expected to be cleared soon:
https://gcc.gnu.org/ml/gcc/2016-11/msg00001.html
- I currently don't know the exact state for glibc.
- None of the kernel code has been upstreamed yet, and this
probably won't change for a while as the RISC-V privileged ISA
spec isn't yet finalized and is undergoing incompatible
changes. Having a fixed privileged ISA spec is a requirement
for getting the kernel code upstream.
One of the bigger problems is that the variable type sizes and
function calling conventions (which parameters get passed in
which registers, which on the stack, in which order, etc.) that
are a part of the ABI aren't completely fixed yet. There have
been recent discussions about introducing some changes possibly
incompatible with older binaries to have calling conventions
which would allow future ISA extensions to be added without
having to break compatibility again, which is generally a good
thing although it might make the older Debian package builds
(partially or completely) unusable.
One example of an incompatible change is the size of a long
double, which has unfortunately been implemented as 8 bytes in
the older toolchain versions but is defined as 16 in the current
ISA spec (and IIRC in the meatime also in the current RISC-V gcc
git head). Defining it as 8 bytes in older toolchain versions
was effectively a mistake as the RISC-V "Q" floting point unit
uses 16 bytes for long double in hardware, so it really doesn't
make sense to have gcc use only 8 bytes instead.
Another open issue concerns the final specification of the
dynamic linker names and paths for the various possible ABIs.
There has been quite a bit of discussion on the topic and Manuel
has proposed corresponding patches to the codebase. Although
there is a rough consensus on how things should be handled,
things haven't been formally set in stone yet.
Regarding the Debian-specific build issues (circular dependencies
etc.), probably Manuel can tell more.
> And about your setup. I've heard in a private mail you are using
> risc-qemu for building. Other people could do the same. Maybe we could
> publish a working qemu disk image and setup?
Qemu is another difficult topic. Qemu and the kernel depend on
the privileged ISA spec, which means that every change in the
privileged ISA spec requires that updates to qemu and to the
kernel are done in lockstep.
For Debian purposes the RISC-V qemu also has one big problem at
the moment: it doesn't have any kind of functional networking
support, so running a buildd in a qemu virtual machine doesn't
really work for now. The RISC-V qemu has recently gained support
for userland emulation that can be used with the Linux
binfmt_misc functionality, but running a buildd using qemu
userland emulation can have its own issues when build systems use
kernel-related information during the build.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: