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

[John Paul Adrian Glaubitz]

Hello Frank,

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.

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

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

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)

- 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

- ia64 uses a 61-bit virtual address space as opposed to the 48-bit virtual
  address space found on 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

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.

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.

Adrian

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