Re: Re-port Intent for HPE NonStop (a.k.a. Tandem)

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 14/03/2022 10:12, Florian Weimer via Libc-help wrote:
>>> Can you use a GCC cross-compiler?
>>
>> No. GCC does not generate code that will run on the platform. While it is
>> x86-based, there are complex endian concerns in the code generator,
>> significant ELF header differences, and major ELF debug section differences
>> that cannot be emitted by GCC. There have been at least 3 unsuccessful
>> attempts I know of to port gcc to the platform and/or to generate cross
>> compile code for it.
> 
> In this case, we would really need an open toolchain, otherwise we can't
> maintain the ELF parts.
> 
> Keep in mind that glibc contains the dynamic linker, so it really has to
> know about the details of your architecture.
> 
>> I have successfully done ports of other products with the same constraint
>> (git, openssh, openssl). Usually ports are possible with minimal
>> changes.
> 
> That's because you rely on the C run-time library to paper over the
> differences in kernel interfaces.  With glibc itself, that's different.
> 
>> I would like to do a bit of an impact analysis to see how difficult
>> this one would be.
> 
> You need to provide the rest of the toolchain first, and that seems to
> require a major effort (and it's not just about writing code).
> 
> I also doubt that we would accept patches which retarget to a
> proprietary kernel, but that depends on how invasive those patches are.
> 
>> How should I proceed, if I need glibc as a dependency?
> 
> You need to port GCC and binutils first, and then you can proceed with
> glibc.  It's how new ports are brought up.  I'm not aware of any other
> port in recent times that has been done in a different way (not using
> GCC).  This is not me being snarky, it's just that the GNU toolchain
> (binutils/GCC/GDB/glibc) is an integrated whole and works best in
> conjunction.

Besides all Florian has pointed out, I am inclined to say that porting 
glibc to a non opensource architecture and also without aiming to be the 
'de facto' loader/libc of the system is a dead-end. Without open-source
support for at least the toolchain pieces, it is really a no-go.

Also, besides probably requiring a lot of work to support any ELF and/or 
ABI extension, the resulting loader won't easily support the system shared
libraries without a compat layer (which imposes another set of issues).
Although there are some examples where it has been done with some relative
success (such as gcompat for musl, or linuxabi for FreeBSD) it a relative
time consuming effort where maintaining this out of tree usually ends up
as a bitrotten project (as we saw for prelink, which was removed recently).

Also, most of the generic interfaces glibc provide is already provided 
by gnulib in a extent. There are other interface that are reliant on proper
kernel support, so using a different kernel might ended required *a lot* of
glue code and, worse, some interfaces might not be actually be proper
implemented.

The truth is glibc is currently Linux oriented projected, there are some
Hurd work but it is moving to nowhere (it barely supports one legacy
architecture).

> 
> It might be possible to get away with an LLVM-based toolchain, but the
> porting of glibc istelf to LLVM is not yet complete, so you would
> struggle on this front as well.
> 

I am working to get glibc in a somewhat usable state with clang [1].
It still requires a *lot* of patches and I still struggling in the
loader bootstrap, but at least it *builds*.

[1] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/clang