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

[John Paul Adrian Glaubitz]

Hello,

On Sun, 2024-05-26 at 14:09 +0200, Frank Scheiner wrote:
> > 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

As I mentioned, getting the math testsuite to pass would require the libm_error.c
code to be adapted that it will work with the new error-handling design. Without
that, FPU error handling will remain broken on ia64.

> 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.

Well, I've had long discussions over this with Adhemerval and he was more reserved
in this announcement mail than in the conversations that we had in private where
he discussed the problems with the port more openly.

> 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.".

The kernel removal may be the main reason, but not the only one.

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

Sure, as I said, I think these efforts are always laudable. I just don't think
there is any chance on getting support re-added upstream to the Linux kernel
and glibc. The majority of developers will vote against it, as hard as that
sounds.

> 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.
> [...]
> ```

I know it doesn't _have_ to be removed from GCC and Binutils. However, removing
it will still relieve the codebase quite a bit and allow for a lot of code
refactoring that people have on their TODO stashes.

> 
> > 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/

There is more involved to maintenance than keeping something buildable and bootable.

You will have to review patches, merge them and send pull requests to Linus and so on.

> > 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.

I don't think these projects that use Ruby in their codebase will waive for it just
because there is no working Ruby interpreter on some (deprecated) platforms.

> 
> > - 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.

ELILO is unmaintained and has had various issues and bugs in the past which is why
I switched to GRUB on Debian back then. But it also looks like that ia64 support
is going to stay in GRUB for a while, I haven't seen any new efforts for removing
it lately on the grub-devel mailing list.

> > - 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.

Well, I have done a lot of work in this regard in the past to get JavaScript fixed on
targets with virtual address space sizes beyond 48 bits. But it's still not fixed
everywhere, especially not in Qt5. It has been fixed in Qt6 though.

> > 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.

I'm not advising against you to do anything. You are free to spend your free time with
whatever you want and if you think that keeping ia64 is worth the effort, more power to
you! All I did was giving an elaborate explanation why ia64 is going to be removed from Debian
within the next days and why I personally think it's a lost cause.

> > 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.

But why would maintainers start an argument with upstream developers over something they don't
really care about? That makes no sense.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913