[debian-mysql] Bug#970043: Request to help test ia64 build for galera-4

[Frank Scheiner]

Hi Adrian,

On 26.05.24 10:58, John Paul Adrian Glaubitz wrote:
> On Sat, 2024-05-25 at 18:29 +0200, Frank Scheiner wrote:
>>> ia64 support has been removed from glibc, the Linux kernel and soon gcc,
>>
>> First - ia64 support was actually removed from the glibc **because** it
>> was removed from Linux.
> 
> It was also removed because there was no maintainer for it in glibc and
> suffered from a lot of testsuite failures. I tried for a long time to
> convince Adhemerval to fix these issues, but he explained that it would
> involve rewriting large parts of the math code for ia64 which he thought
> wasn't worth the effort.

Adhemerval gave his assessment in [2]: "From glibc point of view, 
besides the math issues due the ia64 specific math implementation, the 
port status seems in order."

[2]: https://sourceware.org/pipermail/libc-alpha/2023-November/152497.html

There are "some rough spots" mentioned in addition and also that "There 
are no emulators widely available, and so boot testing Itanium is 
generally infeasible for ordinary contributors."

But all this was not the actual reason to remove ia64 support from the 
glibc. Joseph Meyers added: "We should remove any architecture removed 
from the Linux kernel. [...]" in [3]. And Carlos O'Donell detailed why 
in [4]: "[...] We need an upstream kernel to define the ABI for the 
port. [...]". Adhemerval also added in a later message ([5]): "Sorry, 
but not being upstream is a no start. [...] The best way is to still 
remove it and eventually reinstate it if it were the case.".

So there was no way to keep it in the glibc w/o kernel support for it.

[3]: https://sourceware.org/pipermail/libc-alpha/2023-November/152498.html

[4]: https://sourceware.org/pipermail/libc-alpha/2023-November/152536.html

[5]: https://sourceware.org/pipermail/libc-alpha/2023-November/152522.html

Other than that, we have a working ia64 emulator (Ski) and in the 
meantime, also support for it in Linux was restored ([6]).

[6]: https://github.com/linux-ia64/linux-stable-rc/actions/runs/9240217959

>> Second, how did you come to the conclusion that ia64 support will be
>> removed from the gcc soon?
> 
> gcc usually drops support for a target when it's no longer present in the
> kernel and glibc.

There seem to be different opinions about this "relation": Xi Ruoyao 
pointed out the following recently on the binutils mailing list [7]:

```
The reasoning is incorrect.  The dependency chain of a port is:

- Upstream GCC needs upstream Binutils
- Upstream Linux kernel needs upstream GCC
- Upstream Glibc needs upstream Linux kernel

So the removal of IA64 from the Linux kernel means we should remove it
from Glibc, but you cannot reversely traverse the dependency chain and
claim it should be removed from GCC or Binutils.
[...]
```

[7]: https://sourceware.org/pipermail/binutils/2024-May/134000.html

> That happened in the past and that will happen in the
> future, although there are some targets like Blackfin, CRIS and M32R that
> are still supported by gcc while being dropped by the kernel.
> 
> And since ia64 support has already been marked as deprecated, I expect it
> to be removed from gcc soon. Especially, since ia64 adds a lot of complexity
> to gcc due to its VLIW design.

 From my understanding the main point of the gcc people in regard to 
ia64 is the missing maintainer, but:

>> Rene said he would step up as maintainer for ia64 in gcc - see the
>> thread at [1] - and I haven't heard any different since then.
>>
>> [1]: https://gcc.gnu.org/pipermail/gcc/2024-March/243432.html
>>
>> @Rene: Can you confirm?
> 
> As of now, gcc is still marked as deprecated:
> 
>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=a37113bd00aef1412771f7dd630abebabd444c1f;hb=HEAD#l273
> 
>>> so it will be removed within the next weeks after we have made an archive
>>> copy.
>>>
>>> There is no need to fix any bugs on ia64.
>>
>> Let me correct that for you:
>>
>> There is no need to fix any bugs for ia64 in Debian (Ports) - as sad as
>> that is.
> 
> Have you already sorted out who is going to maintain ia64 support in glibc
> and the Linux kernel?

Well, since quite a while we maintain out-of-tree versions for both 
([8]). Especially for Linux you can follow our progress as replies to 
Linus' release messages to the LKML for 6.7, 6.8 and just recently 6.9 
([9]) and also on https://lore.kernel.org/linux-ia64/.

[8]: https://github.com/orgs/linux-ia64/repositories

[9]: 
https://lore.kernel.org/lkml/d308ad95-bee4-4401-a6f5-27bcf5bcc52d@web.de/

> And do you already know how to get Ruby upstream to
> re-add ia64 support? Ruby is required for a lot of other packages that depend
> on it.

Depending on something like Ruby for a lot of packages is a 
short-sightedness that should eventually be fixed. I didn't need it to 
create a working rebuild of Slackware for ia64. Of course, the package 
selection for EPIC Slack is still limited, but I don't hold anyone back 
or advise against trying to use Ruby on it.

> As someone who has been maintaining many exotic or deprecated architectures
> both in Debian and in the Linux kernel, I know how much work it involves to
> keep a port alive and running. And since I have also maintained ia64 in the
> past and know about all the quirks and problems the port has, I think the
> possibility that the port will ever return upstream to the kernel, glibc
> and the Ruby interpreter is nearly zero.
> 
> To summarize the known issues and quirks on ia64:
> 
> - ia64 has two stacks growing in opposite directions making exception handling
>    in languages like Ruby more complicated and requiring additional code, see:
> 
>    > https://github.com/ruby/ruby/blob/master/doc/NEWS/NEWS-2.7.0 (search for IA64)

I commented on Ruby already above.

> - the VLIW design adds a lot of complexity to the compiler; when it was created,
>    designers expected the design to be superior but it turned out that the
>    implementation was more challenging than expected and left gcc with a lot of
>    unresolved problems on ia64, see:
> 
>    > https://gcc.gnu.org/projects/ia64.html
> 
> - ia64 comes with its own implementation of EFI which is not fully compatible
>    with UEFI and requires additional support code; this was the main reason why
>    some GRUB developers wanted to get rid of ia64 support, see:
> 
>    > https://lists.gnu.org/archive/html/grub-devel/2023-05/msg00051.html

In general I thought that UEFI was derived from EFI, so I don't really 
see, why both can't coexist together. But I might have to do further 
research on that. Apart from that, ELILO is working perfectly fine both 
for diskless boots and booting from disk.

> - ia64 uses a 61-bit virtual address space as opposed to the 48-bit virtual
>    address space found on x86_64;

Yes, it was done earlier than x86_64.

> this causes problems with languages like
>    JavaScript which use tagged pointers to encode type information in the
>    bits unused on x86_64, see:
> 
>    > https://www.ia64-linux.org/doc/IA64linuxkernel.PDF (p. 18)
> 
>    (NB: This is expected to improve in the future as x86_64 optionally supports
>         larger virtual address spaces in the kernel nowadays as well).
> 
> - the math error handling ABI on ia64 in glibc is different from other architectures
>    and the code for it in sysdeps/ia64/fpu/libm_error.c is quite convoluted; as glibc
>    tries to unify and simplify FPU error handling, the different semantics of the ia64
>    ABI would require - quoting Adhemerval here - »a lot boilerplate and mechanical
>    changes« which he doesn't think is worth the effort

I think we could have done more in this regard, if ia64 support wouldn't 
have been removed from Linux last year, requiring additional work 
everywhere. But I don't complain, I think it also forced our hands.

> There are probably more issues and quirks that I don't remember, but I think the list
> above already mentions enough show stoppers which mean that upstream projects won't be
> willing to re-add support for the architecture.

Thanks for your assessment. I consider that much more useful than to 
advise people against working on ia64.

> Of course, I am not going to stop you from continuing your work and I think such efforts
> are always laudable. I just don't think the very limited interest in this architecture
> will be enough to overcome the difficulties that ia64 maintainers have to face.
> 
> This is also the reason why the ia64 maintainers of neither Debian nor Gentoo were against
> the removal of support for the architecture in Ruby, the Linux kernel, glibc and so on.

Being not against something and taking care of something are two 
different things.

Cheers,
Frank