ia64-linux-gnu removal

ia64-linux-gnu removal

[Adhemerval Zanella Netto]

Linux has recently removed ia64 from the official tree [1], so the 
question is whether glibc should keep continue ia64 support.  From 
the commit message, I see that glibc shares some of the views on 
working on IA64 support:

  There are no emulators widely available, and so boot testing Itanium is
  generally infeasible for ordinary contributors. GCC still supports IA-64
  but its compile farm no longer has any IA-64 machines.

From glibc point of view [2], besides the math issues due the ia64
specific math implementation, the port status seems in order. There
are still some rough spots:

  * The math failures will unlikely to be ever fixed, due the work
    required to move ia64 math library to compat symbols.  Even with
    some out-of-tree fixes [3], there are still a lot of 
    failures [4][5] (rought ~200).

  * A recent fix also showed that some compiler generated code are
    fragile and might trigger some latent issues [6].

  * No PT_GNU_RELRO support. I am now sure what is the IA-64 limitation
    that prevents binutils to support it.

  * No static-pie support, although there are still some other ports
    that are not supported as well.

  * Some recent features/tests show regressions on IA64:
    - elf/tst-audit28: audit support;
    - dlfcn/tst-dlinfo-phdr: dlinfo (RTLD_DI_PHDR);
    - elf/tst-ro-dynamic: meaning IA-64 ld.so will most likely to crash 
      loading DSO with read-only dynamic section [7])
    - elf/tst-valgrind-smoke: no valgrind support;

The Linux support removal would require to add on build-many-glibcs.py,
to allow define a kernel version per architecture.

The port removal would be roughly less ~15k lines.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43ff221426d33db909f7159fdf620c3b052e2d1c
[2] https://sourceware.org/glibc/wiki/Release/2.38#IA64
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=10163
[4] https://sourceware.org/bugzilla/show_bug.cgi?id=16401
[5] https://sourceware.org/bugzilla/show_bug.cgi?id=11585
[6] https://sourceware.org/pipermail/libc-alpha/2023-July/150490.html
[7] https://sourceware.org/bugzilla/show_bug.cgi?id=28340

Re: ia64-linux-gnu removal

[Joseph Myers]

On Fri, 3 Nov 2023, Adhemerval Zanella Netto wrote:

> Linux has recently removed ia64 from the official tree [1], so the 
> question is whether glibc should keep continue ia64 support.  From 
> the commit message, I see that glibc shares some of the views on 
> working on IA64 support:

We should remove any architecture removed from the Linux kernel.  Note 
that there are various references to ia64 in non-ia64-specific files to 
remove as well (don't do that in files imported from external sources, 
such as config.guess, config.sub, *.po; longlong.h should have the update 
done in conjunction with removal of support from GCC since it's a shared 
file; and references are still appropriate in contrib.texi, for example; 
references to the C++ ABI as being the IA64 ABI are probably OK though 
maybe a different name for it would be better).  There are also 
ia64-specific open bugs to close as WONTFIX.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: ia64-linux-gnu removal

[Sam James]

Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:

> Linux has recently removed ia64 from the official tree [1], so the 
> question is whether glibc should keep continue ia64 support.  From 
> the commit message, I see that glibc shares some of the views on 
> working on IA64 support:

(CCing ia64 port maintainer, going off https://sourceware.org/glibc/wiki/MAINTAINERS;
see also the removal patch.)

Is there any precedent for the process of removal of a port from glibc? I'm wondering
about timelines especially (given the comments I made in the other
thread wrt both LTS and backporting).

> [...]

thanks,
sam

Re: ia64-linux-gnu removal

[Frank Scheiner]

Dear Adhemerval, all,

On 03.11.23 19:17, Adhemerval Zanella Netto wrote:
> Linux has recently removed ia64 from the official tree [1], so the
> question is whether glibc should keep continue ia64 support.  From
> the commit message, I see that glibc shares some of the views on
> working on IA64 support:
>
>    There are no emulators widely available, and so boot testing Itanium is
>    generally infeasible for ordinary contributors. GCC still supports IA-64
>    but its compile farm no longer has any IA-64 machines.

We are looking into this issue right now. But I believe there chould be
a way to provide contributors with access to ia64 machines, though I
cannot speak for Debian ports and Gentoo which both have ia64 machines
running. I don't have the possibility to run any of my ia64 machines
continuously but I think there could be a way that we could do boot
testing on a case to case basis (e.g. I do regular RC and release
testing for Linux since a while now), and there are multiple additional
people that showed interest to help with their ia64 machines.

Another option in this regard is to use "Ski" (from e.g. [8]), which
according to [8] runs with 4.19.x kernels which have longterm support
until end of next year. [9] shows an example from 2017 of how this can
be used to solve real issues.

[8]: https://github.com/trofi/ski

[9]: https://trofi.github.io/posts/199-ia64-machine-emulation.html

>  From glibc point of view [2], besides the math issues due the ia64
> specific math implementation, the port status seems in order.

That sounds good.

> There
> are still some rough spots:
>
>    * The math failures will unlikely to be ever fixed, due the work
>      required to move ia64 math library to compat symbols.  Even with
>      some out-of-tree fixes [3], there are still a lot of
>      failures [4][5] (rought ~200).

 From what I know, the math situation for ia64 was broken since forever.
Tomas found math issues for ia64 present on every operating system for
Itanium he tested (incl. historical ones). As mentioned in my other
email ([10]), we made some progress in this regard and I think it
shouldn't hurt too much to give us more time with this issue, taking
into account for how long it exists.

[10]: https://sourceware.org/pipermail/libc-alpha/2023-November/152500.html

Cheers,
Frank

>    * A recent fix also showed that some compiler generated code are
>      fragile and might trigger some latent issues [6].
>
>    * No PT_GNU_RELRO support. I am now sure what is the IA-64 limitation
>      that prevents binutils to support it.
>
>    * No static-pie support, although there are still some other ports
>      that are not supported as well.
>
>    * Some recent features/tests show regressions on IA64:
>      - elf/tst-audit28: audit support;
>      - dlfcn/tst-dlinfo-phdr: dlinfo (RTLD_DI_PHDR);
>      - elf/tst-ro-dynamic: meaning IA-64 ld.so will most likely to crash
>        loading DSO with read-only dynamic section [7])
>      - elf/tst-valgrind-smoke: no valgrind support;
>
> The Linux support removal would require to add on build-many-glibcs.py,
> to allow define a kernel version per architecture.
>
> The port removal would be roughly less ~15k lines.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43ff221426d33db909f7159fdf620c3b052e2d1c
> [2] https://sourceware.org/glibc/wiki/Release/2.38#IA64
> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=10163
> [4] https://sourceware.org/bugzilla/show_bug.cgi?id=16401
> [5] https://sourceware.org/bugzilla/show_bug.cgi?id=11585
> [6] https://sourceware.org/pipermail/libc-alpha/2023-July/150490.html
> [7] https://sourceware.org/bugzilla/show_bug.cgi?id=28340

Re: ia64-linux-gnu removal

[Adhemerval Zanella Netto]

On 04/11/23 17:23, Sam James wrote:
> 
> Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
> 
>> Linux has recently removed ia64 from the official tree [1], so the 
>> question is whether glibc should keep continue ia64 support.  From 
>> the commit message, I see that glibc shares some of the views on 
>> working on IA64 support:
> 
> (CCing ia64 port maintainer, going off https://sourceware.org/glibc/wiki/MAINTAINERS;
> see also the removal patch.)
> 
> Is there any precedent for the process of removal of a port from glibc? I'm wondering
> about timelines especially (given the comments I made in the other
> thread wrt both LTS and backporting).

Yes, we removed tilepro (ed95f6114928f00f5f8fe76ccf2ec9e77872cbad) and tilegx 
(a3fb6b6bc3f2f33e93f4c9575105f3b5f39cb201) on 2.27  after the architecture was 
removed on Linux 4.17. And it was done at roughly the same time.

Also, it was the same general principle that general a glibc port needs upstream 
support for *all* the components that prevented the aarch64 ILP32 support to be 
upstream, even when binutils and gcc compiler was upstream and ARM maintained a 
kernel branch for testing (where even some distro kept some minimal build checks).

Re: ia64-linux-gnu removal

[Adhemerval Zanella Netto]

On 04/11/23 18:38, Frank Scheiner wrote:
> Dear Adhemerval, all,
> 
> On 03.11.23 19:17, Adhemerval Zanella Netto wrote:
>> Linux has recently removed ia64 from the official tree [1], so the
>> question is whether glibc should keep continue ia64 support.  From
>> the commit message, I see that glibc shares some of the views on
>> working on IA64 support:
>>
>>    There are no emulators widely available, and so boot testing Itanium is
>>    generally infeasible for ordinary contributors. GCC still supports IA-64
>>    but its compile farm no longer has any IA-64 machines.
> 
> We are looking into this issue right now. But I believe there chould be
> a way to provide contributors with access to ia64 machines, though I
> cannot speak for Debian ports and Gentoo which both have ia64 machines
> running. I don't have the possibility to run any of my ia64 machines
> continuously but I think there could be a way that we could do boot
> testing on a case to case basis (e.g. I do regular RC and release
> testing for Linux since a while now), and there are multiple additional
> people that showed interest to help with their ia64 machines.
Debian gave me access to ia64 machine in the past and it did help me
sort out some issue on some generic fixes.  It would be really helpful
if you could hook it on gcc compile farm, so there is no need setup
another id layer to access such machine.

> 
> Another option in this regard is to use "Ski" (from e.g. [8]), which
> according to [8] runs with 4.19.x kernels which have longterm support
> until end of next year. [9] shows an example from 2017 of how this can
> be used to solve real issues.
> 
> [8]: https://github.com/trofi/ski
> 
> [9]: https://trofi.github.io/posts/199-ia64-machine-emulation.html

Not being able to check with latest kernel version is really limiting,
some of the testing for new support on glibc it exactly to check on
new kernel features.

> 
>>  From glibc point of view [2], besides the math issues due the ia64
>> specific math implementation, the port status seems in order.
> 
> That sounds good.
> 
>> There
>> are still some rough spots:
>>
>>    * The math failures will unlikely to be ever fixed, due the work
>>      required to move ia64 math library to compat symbols.  Even with
>>      some out-of-tree fixes [3], there are still a lot of
>>      failures [4][5] (rought ~200).
> 
> From what I know, the math situation for ia64 was broken since forever.
> Tomas found math issues for ia64 present on every operating system for
> Itanium he tested (incl. historical ones). As mentioned in my other
> email ([10]), we made some progress in this regard and I think it
> shouldn't hurt too much to give us more time with this issue, taking
> into account for how long it exists.
> 
> [10]: https://sourceware.org/pipermail/libc-alpha/2023-November/152500.html

The ia64 math library is really a dead end, its 150k assembly line is pretty
much unmaintainable, it implements some deprecated features that are ia64
specific (matherr{f,l}), and most likely some implementation are subpar
compared to the generic implementation (as x86 has found for some assembly
implementations).

It was also the reason why I have not added support for the new fmod/fmodf 
implementation (16439f419b270184ec501c531bf20d83b6745fb0).

Ideally, one would remove the assembly implementation for the symbols
that has not reason to exist (as I did for htonl and htons, be930668eccf842,
and fabs, efeb2bd1ab492153250); and them adapt each symbol that uses
matherr/__libm_error_region to a compat symbol so ia64 can use the generic
implementation.  As you can see it is a very large project.

> 
> Cheers,
> Frank
> 
>>    * A recent fix also showed that some compiler generated code are
>>      fragile and might trigger some latent issues [6].
>>
>>    * No PT_GNU_RELRO support. I am now sure what is the IA-64 limitation
>>      that prevents binutils to support it.
>>
>>    * No static-pie support, although there are still some other ports
>>      that are not supported as well.
>>
>>    * Some recent features/tests show regressions on IA64:
>>      - elf/tst-audit28: audit support;
>>      - dlfcn/tst-dlinfo-phdr: dlinfo (RTLD_DI_PHDR);
>>      - elf/tst-ro-dynamic: meaning IA-64 ld.so will most likely to crash
>>        loading DSO with read-only dynamic section [7])
>>      - elf/tst-valgrind-smoke: no valgrind support;
>>
>> The Linux support removal would require to add on build-many-glibcs.py,
>> to allow define a kernel version per architecture.

Besides the above issues, ia64 port is also preventing us on new idea to 
simplify the loader self-relocation [1], and even on some bugfixes [2]
where I had a hard time figuring out how kernel would return if a syscall
has side-effects in the instruction bundle (and even not sure if I got
it right).

Also the missing basic features like PT_GNU_RELRO and the discussion about
the 073edbdfabaad4786e974a451efe4b6b3f7a5a61 fix (which is an workaround,
since I think it would better to rewrite the way _dl_sysinfo_break is used
and just avoid the vDSO/stub optimziation in the loader) shows that the
port has some issues that would require a lot of work that no one is really
up to do.

>>
>> The port removal would be roughly less ~15k lines.>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43ff221426d33db909f7159fdf620c3b052e2d1c
>> [2] https://sourceware.org/glibc/wiki/Release/2.38#IA64
>> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=10163
>> [4] https://sourceware.org/bugzilla/show_bug.cgi?id=16401
>> [5] https://sourceware.org/bugzilla/show_bug.cgi?id=11585
>> [6] https://sourceware.org/pipermail/libc-alpha/2023-July/150490.html
>> [7] https://sourceware.org/bugzilla/show_bug.cgi?id=28340


[1] https://sourceware.org/pipermail/binutils/2021-September/118006.html
[2] https://patchwork.sourceware.org/project/glibc/patch/20230524135126.3174670-1-adhemerval.zanella@linaro.org/

Re: ia64-linux-gnu removal

[Carlos O'Donell]

On 11/3/23 15:47, Joseph Myers wrote:
> On Fri, 3 Nov 2023, Adhemerval Zanella Netto wrote:
> 
>> Linux has recently removed ia64 from the official tree [1], so the 
>> question is whether glibc should keep continue ia64 support.  From 
>> the commit message, I see that glibc shares some of the views on 
>> working on IA64 support:
> 
> We should remove any architecture removed from the Linux kernel.  Note 
> that there are various references to ia64 in non-ia64-specific files to 
> remove as well (don't do that in files imported from external sources, 
> such as config.guess, config.sub, *.po; longlong.h should have the update 
> done in conjunction with removal of support from GCC since it's a shared 
> file; and references are still appropriate in contrib.texi, for example; 
> references to the C++ ABI as being the IA64 ABI are probably OK though 
> maybe a different name for it would be better).  There are also 
> ia64-specific open bugs to close as WONTFIX.

I agree.

We need an upstream kernel to define the ABI for the port.

Removing the port at the same time the kernel removes the port is OK.

The LTS kernel can continue to use older versions of glibc e.g. 2.38,
with the ABI that 2.38 is using.

-- 
Cheers,
Carlos.