Will the alpha port be usable for 2.11?

[Thomas Orgis-3]

Dear libc porters...


For the past days I tried to update an install of Source Mage GNU/Linux
(the _other_ source-based distro, of which I probably have the only
Alpha install;-) on my Compaq XP1000 Alpha box, being stuck at
glibc-2.10.1 being reluctant to build for many reasons. I tried the
glibc-ports with lots of patches from Aurelien, basing on his git
repository, grabbing alpha-specific patches from gentoo...

...and in the end realizing that there is not much to gain except pain.
So, from reading in various sources I gather that the Alpha port of
glibc is largely broken since some time now -- though I see that the
update to 2.7 still worked, apparently (since the box is running that
now).

Before I go into detail and bore people with my specific build errors,
which would also probably not be that appropriate for this list, I just
would like to know if the upcoming glibc ports in version 2.11 is
supposed to include a working alpha port. I mean one, that works as-is,
without adding further patches, as that is what Source Mage likes to
use: Vanilla upstream sources, if possible.

I can volunteer to do a bit of testing on my setup to support that goal,
which at least adds a bit of diversity to the current resources, I
guess.


Alrighty then,

Thomas.

[Mike Frysinger]

On Sunday 08 November 2009 11:17:06 Thomas Orgis wrote:
> would like to know if the upcoming glibc ports in version 2.11 is
> supposed to include a working alpha port. I mean one, that works as-is,
> without adding further patches

it is not
-mike

[Carlos O'Donell-2]

On Sun, Nov 8, 2009 at 11:17 AM, Thomas Orgis <sobukus@...> wrote:
> I can volunteer to do a bit of testing on my setup to support that goal,
> which at least adds a bit of diversity to the current resources, I
> guess.

Unfortunately what the project needs is maintainer for alpha. AFAIK
the 2.11 libc-ports is not in a working condition.

Cheers,
Carlos.

[Thomas Orgis-3]

Am Sun, 8 Nov 2009 11:22:40 -0500
schrieb Mike Frysinger <vapier@...>:

> On Sunday 08 November 2009 11:17:06 Thomas Orgis wrote:
> > [alpha support in glibc-ports 2.11]
>
> it is not
> -mike

Oh, thanks for the quick answer. So I suppose the only way to get
recent glibc working on alpha would be to mirror the patches gentoo
uses? Or is the ebuild also broken? I mean, in that case I would know
that I should either drop it or downgrade our glibc spell to 2.7, the
last known-to-work version.

It's a bit sad, though. But I see the point that there are limited
resources to maintain the port. Heck, I don't even have the free time
that I spent already on taking care of the Source Mage port to alpha.


Alrighty then,

Thomas.

[Mike Frysinger]

On Sunday 08 November 2009 11:29:39 Thomas Orgis wrote:

> Am Sun, 8 Nov 2009 11:22:40 -0500 schrieb Mike Frysinger:
> > On Sunday 08 November 2009 11:17:06 Thomas Orgis wrote:
> > > [alpha support in glibc-ports 2.11]
> >
> > it is not
>
> Oh, thanks for the quick answer. So I suppose the only way to get
> recent glibc working on alpha would be to mirror the patches gentoo
> uses? Or is the ebuild also broken? I mean, in that case I would know
> that I should either drop it or downgrade our glibc spell to 2.7, the
> last known-to-work version.

Gentoo's 2.10.1 should be working now (and i'm using it).  i havent tried 2.11
yet because there is no libc-port 2.11 tarball because no one has created a
glibc-2.11 tag in the ports tree.  once someone creates the tag, and i can
poke someone to make the tarball, i'll look at getting it working under alpha.
-mike

[Joseph S. Myers]

On Sun, 8 Nov 2009, Thomas Orgis wrote:

> Before I go into detail and bore people with my specific build errors,
> which would also probably not be that appropriate for this list, I just
> would like to know if the upcoming glibc ports in version 2.11 is
> supposed to include a working alpha port. I mean one, that works as-is,

Ultimately, it is up to port maintainers to keep their ports working,
including updating them for changes in libc code and reviewing patches
from others to their ports.

Fairly soon we're going to need to tag 2.11 and make the 2.11 branch for
ports.  So let's look at the status of ports and what port maintainers
would need to do to bring them up to date for 2.11, and maintainers can
comment on what they might be doing in that regard and when so it can
inform the decision as to when to tag and branch.

* ARM and MIPS are as far as I know fully up to date (including all three
MIPS ABIs).  (I have never tested ARM old-ABI and have no information
about whether it still works, although I do not know of any problems with
it either.)

* I haven't tested Power soft-float lately, but I don't know of anything
out-of-date with it.

* M68K has patches pending review to bring it up to date by adding NPTL
support.  There's some dependence on kernel patches, although I think the
kernel maintainers did reserve the syscall numbers 333-336 required.  
Patches to bring bits/fcntl.h in sync with libc as regards F_GETOWN_EX
etc. are waiting on the kernel resolving problems with the numbering of
those values, at which point most or all architectures will need to update
their settings for these constants (that will presumably happen on 2.11
branch of libc as well as on trunk).

Only the architectures above have an ____longjmp_chk implementation, which
is required for 2.11 to build at all and requires rather more
architecture-specific knowledge to implement than most ports updates for
libc changes do.  But these are the other architectures with GNU/Linux
target support in ports, and their status.  Getting any of these up to
date would require someone to go through all the sysdeps files, compare
with corresponding libc files and look at logs of changes to those files
since the target moved out of libc.  I did that a while ago for m68k
<http://sourceware.org/ml/libc-ports/2008-08/msg00005.html>.  Most such
updates - with a few exceptions such as ____longjmp_chk - are reasonably
straightforward and mechanical.  Anyone adding ____longjmp_chk
implementations may wish to see my discussion of the logic involved
<http://sourceware.org/ml/libc-ports/2009-08/msg00002.html>.

* Alpha.  No maintainer (though RTH may review some patches), needs ports
files updates and ____longjmp_chk implementation.

* HPPA.  Maintained by Carlos.  Needs ports files updates and
____longjmp_chk implementation.  One HPPA bug (6676) is marked with the
glibc_2.11 keyword.

The following architectures do not have an NPTL implementation.

* AM33 (MN10300).  No maintainer.  Needs ports files updates,
____longjmp_chk and NPTL implementations.

* CRIS.  No maintainer.  Needs ports files updates, ____longjmp_chk and
NPTL implementations.  Unlike AM33, does have TLS support in binutils, but
not in GCC.

I am reluctant to review and apply patches for architectures I know
nothing about; I might consider it for purely mechanical patches to
unmaintained architectures, and review patches for Power soft-float as
well as the architectures I more specifically maintain, but in general if
people are fixing unmaintained architectures they should become
maintainers for those architectures.

--
Joseph S. Myers
joseph@...

[Carlos O'Donell-2]

On Sun, Nov 8, 2009 at 11:48 AM, Joseph S. Myers
<joseph@...> wrote:

> On Sun, 8 Nov 2009, Thomas Orgis wrote:
>
>> Before I go into detail and bore people with my specific build errors,
>> which would also probably not be that appropriate for this list, I just
>> would like to know if the upcoming glibc ports in version 2.11 is
>> supposed to include a working alpha port. I mean one, that works as-is,
>
> Ultimately, it is up to port maintainers to keep their ports working,
> including updating them for changes in libc code and reviewing patches
> from others to their ports.

I've been working on the hppa port this weekend.

> * HPPA.  Maintained by Carlos.  Needs ports files updates and
> ____longjmp_chk implementation.  One HPPA bug (6676) is marked with the
> glibc_2.11 keyword.

The ____longjmp_check implementation will be checked in by the end of today.

The PIE fix will also be checked in by the end of today.

Unforutnately in addition to this I had to implement the
_STACK_GROWS_UP case for nptl/pthread_create.c, which is currently
#error "to do", therefore the hppa port will never compile with 2.11
because of this and upstream is already tagged.

I don't know if upstream will be willing to create a 2.11.1 with the
_STACK_GROWS_UP fix.

Cheers,
Carlos.

[Joseph S. Myers]

One further point I forgot:

The recent libc patch

2009-11-03  Andreas Schwab  <schwab@...>

        [BZ #4457]
        * sysdeps/generic/libgcc_s.h: New file.
        * sysdeps/generic/framestate.c: Include it and use LIBGCC_S_SO.

should help both M68K and HPPA, which use libgcc_s.so.2 and libgcc_s.so.4
instead of libgcc_s.so.1.  M68K needs additional libc changes to add TLS
relocations to elf.h
<http://sourceware.org/ml/libc-ports/2009-08/msg00012.html>, but that sort
of change should be safe to go in libc on 2.11 branch as well as trunk.  
NPTL additions for other targets (AM33, CRIS) would also need relocations;
unless they are completely ready right now I think they'd need to wait for
2.12 or later.

--
Joseph S. Myers
joseph@...

[Joseph S. Myers]

On Sun, 8 Nov 2009, Carlos O'Donell wrote:

> I've been working on the hppa port this weekend.
>
> > * HPPA.  Maintained by Carlos.  Needs ports files updates and
> > ____longjmp_chk implementation.  One HPPA bug (6676) is marked with the
> > glibc_2.11 keyword.
>
> The ____longjmp_check implementation will be checked in by the end of today.
>
> The PIE fix will also be checked in by the end of today.

Thanks.  What are your plans regarding miscellaneous sysdeps files that
have changed in libc over the past few years in ways that need
corresponding hppa updates?  (bits/fcntl.h is one of the most frequently
changing, but probably not the only one.  Some updates are perhaps less
obvious - for example, fallocate64 exports
<http://sourceware.org/ml/libc-hacker/2009-05/msg00003.html> or ensuring
that identifiers in headers that are not part of the public API, such as
parameter names, have their proper leading "__".  Certainly for
fallocate64 you need to decide whether it is or is not exported at version
2.11.)

> Unforutnately in addition to this I had to implement the
> _STACK_GROWS_UP case for nptl/pthread_create.c, which is currently
> #error "to do", therefore the hppa port will never compile with 2.11
> because of this and upstream is already tagged.

We know neither HPPA nor M68K can work perfectly with 2.11 tag, simply
because the support for different libgcc_s sonames went into libc after
that tag (but before the branch), and M68K also needs elf.h changes.  But
I'd hope they can work with future versions on 2.11 branch (whether or not
there is a 2.11.1 release).

--
Joseph S. Myers
joseph@...

[Carlos O'Donell-2]

On Sun, Nov 8, 2009 at 12:19 PM, Joseph S. Myers
<joseph@...> wrote:

> On Sun, 8 Nov 2009, Carlos O'Donell wrote:
> Thanks.  What are your plans regarding miscellaneous sysdeps files that
> have changed in libc over the past few years in ways that need
> corresponding hppa updates?  (bits/fcntl.h is one of the most frequently
> changing, but probably not the only one.  Some updates are perhaps less
> obvious - for example, fallocate64 exports
> <http://sourceware.org/ml/libc-hacker/2009-05/msg00003.html> or ensuring
> that identifiers in headers that are not part of the public API, such as
> parameter names, have their proper leading "__".  Certainly for
> fallocate64 you need to decide whether it is or is not exported at version
> 2.11.)

I have no general plans to fix the miscellaneous sysdep files that
need hppa updates.

If debian reports any serious problems and those problems are fixed by
updating sysdep files then I will fix them.

Otherwise, I have much higher priority issues to deal with on the hppa
port including fixes to gcj, libstdc++ and the kernel.

I do have plans to fix fcntl.h which is the most important of the
changed sysdep files.

My hppa ports tree has:
* fallocate64 patches exporting them at 2.11.
* fcntl.h patches to add missing defines.
* LIBGCC_S_SO fixes.
* __longjmp fixes.
* ____longjmp_chk implementation.
* Fix dl-trampoline.S pltexit and pltenter problems.
* -fPIE fixes.
* bits/socket.h fixes.

My hppa libc tree has:
* nptl pthread_create _S_G_U fixes.

I have also marked all the hppa issues with keywords glibc_2.11 or
milestone 2.12 to indicate where they are needed and when I plan to
fix them.

>> Unforutnately in addition to this I had to implement the
>> _STACK_GROWS_UP case for nptl/pthread_create.c, which is currently
>> #error "to do", therefore the hppa port will never compile with 2.11
>> because of this and upstream is already tagged.
>
> We know neither HPPA nor M68K can work perfectly with 2.11 tag, simply
> because the support for different libgcc_s sonames went into libc after
> that tag (but before the branch), and M68K also needs elf.h changes.  But
> I'd hope they can work with future versions on 2.11 branch (whether or not
> there is a 2.11.1 release).

Yes, I agree, I will get the patches onto the 2.11 branch if the
branch maintainer agrees.

Cheers,
Carlos.

[Carlos O'Donell-2]

On Sun, Nov 8, 2009 at 12:05 PM, Joseph S. Myers
<joseph@...> wrote:

> One further point I forgot:
>
> The recent libc patch
>
> 2009-11-03  Andreas Schwab  <schwab@...>
>
>        [BZ #4457]
>        * sysdeps/generic/libgcc_s.h: New file.
>        * sysdeps/generic/framestate.c: Include it and use LIBGCC_S_SO.
>
> should help both M68K and HPPA, which use libgcc_s.so.2 and libgcc_s.so.4
> instead of libgcc_s.so.1.

Thanks! I had forgotten about that. I've fixed this up for hppa now.

I'm about to mark #4457 as fixed on trunk, but needed on glibc_2.11,
who is the branch maintainer for glibc_2.11?

Has a glibc_2.11 branch maintainer been named?

Cheers,
Carlos.

[Joseph S. Myers]

On Sun, 8 Nov 2009, Carlos O'Donell wrote:

> I'm about to mark #4457 as fixed on trunk, but needed on glibc_2.11,
> who is the branch maintainer for glibc_2.11?

I am presuming that when 2.11 branches it will do so based on current
master (not on the 2.11 tag) and so all fixes checked in to libc so far
will be on 2.11 branch.

--
Joseph S. Myers
joseph@...

[Carlos O'Donell-2]

On Sun, Nov 8, 2009 at 12:59 PM, Joseph S. Myers
<joseph@...> wrote:
> On Sun, 8 Nov 2009, Carlos O'Donell wrote:
>
>> I'm about to mark #4457 as fixed on trunk, but needed on glibc_2.11,
>> who is the branch maintainer for glibc_2.11?
>
> I am presuming that when 2.11 branches it will do so based on current
> master (not on the 2.11 tag) and so all fixes checked in to libc so far
> will be on 2.11 branch.

What purpose does the 2.11 tag serve if the branch isn't made from that tag?

Cheers,
Carlos.

[Joseph S. Myers]

On Sun, 8 Nov 2009, Carlos O'Donell wrote:

> On Sun, Nov 8, 2009 at 12:59 PM, Joseph S. Myers
> <joseph@...> wrote:
> > On Sun, 8 Nov 2009, Carlos O'Donell wrote:
> >
> >> I'm about to mark #4457 as fixed on trunk, but needed on glibc_2.11,
> >> who is the branch maintainer for glibc_2.11?
> >
> > I am presuming that when 2.11 branches it will do so based on current
> > master (not on the 2.11 tag) and so all fixes checked in to libc so far
> > will be on 2.11 branch.
>
> What purpose does the 2.11 tag serve if the branch isn't made from that tag?

The same purpose or lack thereof of any release.  glibc has for a long
time followed the practice of making a release from trunk and branching
some time after the release, from a later trunk point, rather than making
the release also serve as the branchpoint.  You could also branch at the
release point, or before the release point.

--
Joseph S. Myers
joseph@...

[Mike Frysinger]

On Sunday 08 November 2009 13:29:45 Carlos O'Donell wrote:

> On Sun, Nov 8, 2009 at 12:59 PM, Joseph S. Myers wrote:
> > On Sun, 8 Nov 2009, Carlos O'Donell wrote:
> >> I'm about to mark #4457 as fixed on trunk, but needed on glibc_2.11,
> >> who is the branch maintainer for glibc_2.11?
> >
> > I am presuming that when 2.11 branches it will do so based on current
> > master (not on the 2.11 tag) and so all fixes checked in to libc so far
> > will be on 2.11 branch.
>
> What purpose does the 2.11 tag serve if the branch isn't made from that
>  tag?

while it sounds a little backwards, it doesnt make much practical difference.  
think of the branch and tag being created at the same time, but then some
changes are added to the branch after the tag.  the fact that the changes are
also in trunk doesnt matter too much.
-mike

[Carlos O'Donell-2]

On Sun, Nov 8, 2009 at 12:03 PM, Carlos O'Donell
<carlos@...> wrote:
> The ____longjmp_check implementation will be checked in by the end of today.

This will be another day at a minimum. I've run across another problem
which has been blocking my testing.

The value of GLRO(dl_pagesize) ends up being zero in the dynamic
linker and this causes dl-fptr.c code to try mmap a zero sized area,
and everything fails after that. I'm tracking down what is the cause
of this failure (kernel returning zero in AT_PAGESZ?).

I might just force GLRO(dl_pagesize) to something sensible in _dl_start.

Cheers,
Carlos.