Re: Welcome to the list!
Hi Karsten!
2016-11-09 15:21 Karsten Merker:
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:
Great summary, thanks!
- 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.
If things come to the worst, presumably these changes could be applied
mechanically, patching existing binaries (changing some bits in the elf
header)?
Not sure yet how to do it, but it could be a better alternative than
recompiling things for months...
- 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 would have thought that they tackled together all copyright assignment
at the same time, at least for GNU projects!
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.
Ugh, if that happened/happens, that will hurt!
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.
Hopefully this will only affect to some packages, not most and not the
most basic ones, I hope.
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.
Yeah, I have that pending too since May or so :-/
I think that this can be hacked around with symlinks in the systems
before the change, at least.
Regarding the Debian-specific build issues (circular dependencies
etc.), probably Manuel can tell more.
I explained that in another e-mail, and if many/most/all packages are
affected it will be a hassle to redo that work :(
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.
I think that the good news on that is that all userland packages are not
affected, one only has to care about qemu and the kernel be updated in
lockstep, as you say.
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.
Yes, the biggest shortcoming of qemu is not having network, virtio or
even being able to mount more than one disk at once :-/
I suppose that the userland emulation can have subtle issues that cause
the same or similar problems as cross-compilation not working in some
cases. I tried qemu-user with binfmt_misc a while ago but without much
success, qemu-system is slower but seems to work mostly fine :)
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: