Re: Request to help test ia64 build for galera-4

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 though=
t
> > wasn't worth the effort.
>=20
> Adhemerval gave his assessment in [2]: "From glibc point of view,=20
> besides the math issues due the ia64 specific math implementation, the=
=20
> port status seems in order."
>=20
> [2]: https://sourceware.org/pipermail/libc-alpha/2023-November/152497.htm=
l

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

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

Well, I've had long discussions over this with Adhemerval and he was more r=
eserved
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=
=20
> glibc. Joseph Meyers added: "We should remove any architecture removed=
=20
> from the Linux kernel. [...]" in [3]. And Carlos O'Donell detailed why=
=20
> in [4]: "[...] We need an upstream kernel to define the ABI for the=20
> port. [...]". Adhemerval also added in a later message ([5]): "Sorry,=20
> but not being upstream is a no start. [...] The best way is to still=20
> 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=20
> 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 th=
ink
there is any chance on getting support re-added upstream to the Linux kerne=
l
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=20
> pointed out the following recently on the binutils mailing list [7]:
>=20
> ```
> The reasoning is incorrect.  The dependency chain of a port is:
>=20
> - Upstream GCC needs upstream Binutils
> - Upstream Linux kernel needs upstream GCC
> - Upstream Glibc needs upstream Linux kernel
>=20
> 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, remo=
ving
it will still relieve the codebase quite a bit and allow for a lot of code
refactoring that people have on their TODO stashes.

>=20
> > Have you already sorted out who is going to maintain ia64 support in gl=
ibc
> > and the Linux kernel?
>=20
> Well, since quite a while we maintain out-of-tree versions for both=20
> ([8]). Especially for Linux you can follow our progress as replies to=20
> Linus' release messages to the LKML for 6.7, 6.8 and just recently 6.9=
=20
> ([9]) and also on https://lore.kernel.org/linux-ia64/.
>=20
> [8]: https://github.com/orgs/linux-ia64/repositories
>=20
> [9]:=20
> https://lore.kernel.org/lkml/[email protected]/

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.
>=20
> Depending on something like Ruby for a lot of packages is a=20
> short-sightedness that should eventually be fixed. I didn't need it to=
=20
> create a working rebuild of Slackware for ia64. Of course, the package=
=20
> selection for EPIC Slack is still limited, but I don't hold anyone back=
=20
> 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=
.

>=20
> > - ia64 comes with its own implementation of EFI which is not fully comp=
atible
> >    with UEFI and requires additional support code; this was the main re=
ason why
> >    some GRUB developers wanted to get rid of ia64 support, see:
> >=20
> >    > https://lists.gnu.org/archive/html/grub-devel/2023-05/msg00051.htm=
l
>=20
> In general I thought that UEFI was derived from EFI, so I don't really=
=20
> see, why both can't coexist together. But I might have to do further=20
> research on that. Apart from that, ELILO is working perfectly fine both=
=20
> 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 su=
pport
is going to stay in GRUB for a while, I haven't seen any new efforts for re=
moving
it lately on the grub-devel mailing list.

> > - ia64 uses a 61-bit virtual address space as opposed to the 48-bit vir=
tual
> >    address space found on x86_64;
>=20
> Yes, it was done earlier than x86_64.
>=20
> > this causes problems with languages like
> >    JavaScript which use tagged pointers to encode type information in t=
he
> >    bits unused on x86_64, see:
> >=20
> >    > https://www.ia64-linux.org/doc/IA64linuxkernel.PDF (p. 18)
> >=20
> >    (NB: This is expected to improve in the future as x86_64 optionally =
supports
> >         larger virtual address spaces in the kernel nowadays as well).
> >=20
> > - 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 convol=
uted; as glibc
> >    tries to unify and simplify FPU error handling, the different semant=
ics of the ia64
> >    ABI would require - quoting Adhemerval here - =C2=BBa lot boilerplat=
e and mechanical
> >    changes=C2=AB which he doesn't think is worth the effort
>=20
> I think we could have done more in this regard, if ia64 support wouldn't=
=20
> have been removed from Linux last year, requiring additional work=20
> 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 JavaScrip=
t 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 pr=
ojects won't be
> > willing to re-add support for the architecture.
>=20
> Thanks for your assessment. I consider that much more useful than to=20
> advise people against working on ia64.

I'm not advising against you to do anything. You are free to spend your fre=
e time with
whatever you want and if you think that keeping ia64 is worth the effort, m=
ore 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 t=
hink such efforts
> > are always laudable. I just don't think the very limited interest in th=
is architecture
> > will be enough to overcome the difficulties that ia64 maintainers have =
to face.
> >=20
> > 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.
>=20
> Being not against something and taking care of something are two=20
> different things.

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

Adrian

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