• glibc regression on alpha with 2.34+

    From John Paul Adrian Glaubitz@21:1/5 to All on Sun Nov 13 00:50:01 2022
    Hello!

    I just noticed that there is a regression in glibc on alpha with version 2.34 or later.

    Looking at the build logs for Debian's 2.34-8 [1], 2.35-4 [2] and 2.36-4 [3], it's obvious
    there is something wrong given the many "Segmentation Fault" errors.

    I had hoped I could fix this issue by passing "--disable-default-pie" like we already did
    on sparc64, but it seems it's not the same bug [4]. At least, this particular workaround
    does not help.

    I think the best approach would be bisecting this from 2.33 to 2.34 using the glibc sources
    from git. I assume building glibc and running the testsuite should be enough for bisecting.

    Adrian

    [1] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=alpha&ver=2.34-8&stamp=1662963628&raw=0
    [2] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=alpha&ver=2.35-4&stamp=1666729919&raw=0
    [3] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=alpha&ver=2.36-4&stamp=1667607306&raw=0
    [4] https://sourceware.org/bugzilla/show_bug.cgi?id=29575

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Cree@21:1/5 to John Paul Adrian Glaubitz on Sun Nov 20 10:50:01 2022
    On Sun, Nov 13, 2022 at 12:45:17AM +0100, John Paul Adrian Glaubitz wrote:
    I just noticed that there is a regression in glibc on alpha with version 2.34 or later.

    Looking at the build logs for Debian's 2.34-8 [1], 2.35-4 [2] and 2.36-4 [3], it's obvious
    there is something wrong given the many "Segmentation Fault" errors.

    I had hoped I could fix this issue by passing "--disable-default-pie" like we already did
    on sparc64, but it seems it's not the same bug [4]. At least, this particular workaround
    does not help.

    Interestingly the vast number of the failing tests pass if one builds
    with a compiler that raises the baseline to EV67. This has been
    proposed a number of times in the past for the Debian distribution.
    I think it is time we did it. One of our last EV56 users has recently
    bowed out due to hardware failure and I am only running EV67 hardware.

    Cheers
    Michael.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kirsten Bromilow@21:1/5 to All on Sun Nov 20 14:00:01 2022
    Please remove my email from your mailing lIst!

    Sent from my iPhone

    On 20 Nov 2022, at 12:48, Frank Scheiner <frank.scheiner@web.de> wrote:

    On 20.11.22 10:03, Michael Cree wrote:
    On Sun, Nov 13, 2022 at 12:45:17AM +0100, John Paul Adrian Glaubitz wrote: >>> I just noticed that there is a regression in glibc on alpha with version 2.34 or later.

    Looking at the build logs for Debian's 2.34-8 [1], 2.35-4 [2] and 2.36-4 [3], it's obvious
    there is something wrong given the many "Segmentation Fault" errors.

    I had hoped I could fix this issue by passing "--disable-default-pie" like we already did
    on sparc64, but it seems it's not the same bug [4]. At least, this particular workaround
    does not help.

    Interestingly the vast number of the failing tests pass if one builds
    with a compiler that raises the baseline to EV67. This has been
    proposed a number of times in the past for the Debian distribution.
    I think it is time we did it. One of our last EV56 users has recently
    bowed out due to hardware failure and I am only running EV67 hardware.

    I still have the following pre EV67 machines available and in working order:

    * AXPpci 33 (LCA4)
    * AlphaStation 200 (EV4) / 255 (EV45) / 500 (EV56)
    * PWS 500au (EV56)
    * AlphaServer 800 (EV56)

    ...and can provide testing on them. All of them eventually ran Debian GNU/Linux Sid with up to Linux 5.x.x IIRC and I will also try them with 6.0.x. And I believe the majority of still exsiting, still working Alpha systems are pre EV67 systems.

    Given the fact that EV6[...] and EV7[...] based systems are nowadays
    very expensive for hobby use (I don't want to say unobtainium), I expect
    that dropping support for pre EV67 will kill off most of the user base
    for Debian on Alpha (and also Gentoo I assume).

    Phrasing it differently:

    Who needs a port that only runs on the buildds and a handful of
    (hobbyist) machines around the world (like ppc64le ;-))?

    My two cents.

    All the best,
    Frank


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to Michael Cree on Sun Nov 20 13:50:02 2022
    On 20.11.22 10:03, Michael Cree wrote:
    On Sun, Nov 13, 2022 at 12:45:17AM +0100, John Paul Adrian Glaubitz wrote:
    I just noticed that there is a regression in glibc on alpha with version 2.34 or later.

    Looking at the build logs for Debian's 2.34-8 [1], 2.35-4 [2] and 2.36-4 [3], it's obvious
    there is something wrong given the many "Segmentation Fault" errors.

    I had hoped I could fix this issue by passing "--disable-default-pie" like we already did
    on sparc64, but it seems it's not the same bug [4]. At least, this particular workaround
    does not help.

    Interestingly the vast number of the failing tests pass if one builds
    with a compiler that raises the baseline to EV67. This has been
    proposed a number of times in the past for the Debian distribution.
    I think it is time we did it. One of our last EV56 users has recently
    bowed out due to hardware failure and I am only running EV67 hardware.

    I still have the following pre EV67 machines available and in working order:

    * AXPpci 33 (LCA4)
    * AlphaStation 200 (EV4) / 255 (EV45) / 500 (EV56)
    * PWS 500au (EV56)
    * AlphaServer 800 (EV56)

    ...and can provide testing on them. All of them eventually ran Debian
    GNU/Linux Sid with up to Linux 5.x.x IIRC and I will also try them with
    6.0.x. And I believe the majority of still exsiting, still working Alpha systems are pre EV67 systems.

    Given the fact that EV6[...] and EV7[...] based systems are nowadays
    very expensive for hobby use (I don't want to say unobtainium), I expect
    that dropping support for pre EV67 will kill off most of the user base
    for Debian on Alpha (and also Gentoo I assume).

    Phrasing it differently:

    Who needs a port that only runs on the buildds and a handful of
    (hobbyist) machines around the world (like ppc64le ;-))?

    My two cents.

    All the best,
    Frank

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Cree@21:1/5 to Frank Scheiner on Mon Dec 12 08:30:01 2022
    On Sun, Nov 20, 2022 at 01:47:59PM +0100, Frank Scheiner wrote:
    On 20.11.22 10:03, Michael Cree wrote:
    On Sun, Nov 13, 2022 at 12:45:17AM +0100, John Paul Adrian Glaubitz wrote:
    I just noticed that there is a regression in glibc on alpha with version 2.34 or later.

    Interestingly the vast number of the failing tests pass if one builds
    with a compiler that raises the baseline to EV67. This has been
    proposed a number of times in the past for the Debian distribution.
    I think it is time we did it. One of our last EV56 users has recently bowed out due to hardware failure and I am only running EV67 hardware.

    I still have the following pre EV67 machines available and in working order:

    * AXPpci 33 (LCA4)
    * AlphaStation 200 (EV4) / 255 (EV45) / 500 (EV56)
    * PWS 500au (EV56)
    * AlphaServer 800 (EV56)

    ...and can provide testing on them. All of them eventually ran Debian

    Can you fix the ev4 based bugs in glibc? If not, I am not interested.

    With the usrmerge uploads now depending on a recent libc version Alpha
    is now dead in the water. Nothing can be built. Thus we have to fix
    glibc to continue building.

    I am not prepared to fix ev4 issues so if no one else is prepared to
    fix them then without a architecture baseline raise this is the end
    of Alpha on Debian Ports.

    Given that ev67 fixed the glibc test suite failures, and that it is
    most likely BWX that is the issue, I am going to work towards
    upping the baseline Alpha architecture to include BWX, i.e. ev56, in
    Debian ports. It will probably take me a few days work to rebuild
    gcc and glibc with the baseline raised and fix any remaining issues
    in glibc.

    So if people want the baseline to remain at ev4 you have a few days
    to fix all the test suite failures in glibc before I upload the raise
    of the architecture baseline.

    Cheers
    Michael.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to All on Mon Dec 12 09:10:01 2022
    Hi Frank!

    On Dec 12, 2022, at 8:57 AM, Frank Scheiner <frank.scheiner@web.de> wrote:

    I'm not sure I fully understand the issue here:

    See, glibc used to work for alpha up until 2.33 as I read. Then a change broke it for alpha with 2.34. Does the respective glibc maintainer for
    alpha (Richard Henderson according to [1]) really have no interest in
    fixing it?

    Any chance you can bisect the issue?

    FWIW, it’s not been reported upstream yet.

    Adrian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to Michael Cree on Mon Dec 12 09:10:01 2022
    Dear Michael,

    On 12.12.22 08:27, Michael Cree wrote:
    On Sun, Nov 20, 2022 at 01:47:59PM +0100, Frank Scheiner wrote:
    On 20.11.22 10:03, Michael Cree wrote:
    On Sun, Nov 13, 2022 at 12:45:17AM +0100, John Paul Adrian Glaubitz wrote: >>>> I just noticed that there is a regression in glibc on alpha with version 2.34 or later.

    Interestingly the vast number of the failing tests pass if one builds
    with a compiler that raises the baseline to EV67. This has been
    proposed a number of times in the past for the Debian distribution.
    I think it is time we did it. One of our last EV56 users has recently
    bowed out due to hardware failure and I am only running EV67 hardware.

    I still have the following pre EV67 machines available and in working order: >>
    * AXPpci 33 (LCA4)
    * AlphaStation 200 (EV4) / 255 (EV45) / 500 (EV56)
    * PWS 500au (EV56)
    * AlphaServer 800 (EV56)

    ...and can provide testing on them. All of them eventually ran Debian

    Can you fix the ev4 based bugs in glibc? If not, I am not interested.

    I already told you what I can provide.

    With the usrmerge uploads now depending on a recent libc version Alpha
    is now dead in the water. Nothing can be built. Thus we have to fix
    glibc to continue building.

    I am not prepared to fix ev4 issues so if no one else is prepared to
    fix them then without a architecture baseline raise this is the end
    of Alpha on Debian Ports.

    I'm not sure I fully understand the issue here:

    See, glibc used to work for alpha up until 2.33 as I read. Then a change
    broke it for alpha with 2.34. Does the respective glibc maintainer for
    alpha (Richard Henderson according to [1]) really have no interest in
    fixing it?

    [1]: https://sourceware.org/glibc/wiki/MAINTAINERS#Machine_maintainers

    Cheers,
    Frank

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Cree@21:1/5 to John Paul Adrian Glaubitz on Mon Dec 12 09:30:01 2022
    On Mon, Dec 12, 2022 at 09:02:23AM +0100, John Paul Adrian Glaubitz wrote:
    Hi Frank!

    On Dec 12, 2022, at 8:57 AM, Frank Scheiner <frank.scheiner@web.de> wrote:

    I'm not sure I fully understand the issue here:

    See, glibc used to work for alpha up until 2.33 as I read. Then a change broke it for alpha with 2.34. Does the respective glibc maintainer for alpha (Richard Henderson according to [1]) really have no interest in fixing it?

    Any chance you can bisect the issue?

    FWIW, it’s not been reported upstream yet.

    I am not interested in supporting old Alphas without BWX anymore.
    I am drawing the line. Either someone steps up to support non-BWX
    Alpha and promptly fixes glibc or the architecture baseline is
    increased to include BWX (thereby fixing most of the glibc issues).
    Without either of those happening I give up being an Alpha porter
    and switch off my Alpha buildd permanently. I have many other
    interesting projects I could be working on!

    Regards,
    Michael.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Cree@21:1/5 to Frank Scheiner on Mon Dec 12 09:20:01 2022
    On Mon, Dec 12, 2022 at 08:56:40AM +0100, Frank Scheiner wrote:
    Dear Michael,

    On 12.12.22 08:27, Michael Cree wrote:
    With the usrmerge uploads now depending on a recent libc version Alpha
    is now dead in the water. Nothing can be built. Thus we have to fix
    glibc to continue building.

    I am not prepared to fix ev4 issues so if no one else is prepared to
    fix them then without a architecture baseline raise this is the end
    of Alpha on Debian Ports.

    I'm not sure I fully understand the issue here:

    See, glibc used to work for alpha up until 2.33 as I read. Then a change broke it for alpha with 2.34. Does the respective glibc maintainer for
    alpha (Richard Henderson according to [1]) really have no interest in
    fixing it?

    RTH hasn't had working Alpha hardware for quite some time.

    One of the glibc maintainers did have access to one of my Alphas
    until last year but unfortunately the hosting site is no longer
    prepared to host it so I can no longer make that Alpha available
    to developers.

    So with that glibc Alpha support is rotting fast.

    Many of the other ports (e.g. armel, armhf, i386) have had
    architecture baseline increases in the last few years, and none
    support hardware anywhere near as old as alpha ev4.

    I am no longer personally prepared to support Alpha unless
    the architecture baseline increase is done. I have no
    ev4/ev45 hardware and no longer have any interest in supporting
    them.

    Regards,
    Michael.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to Michael Cree on Mon Dec 12 10:40:01 2022
    On 12.12.22 09:17, Michael Cree wrote:
    On Mon, Dec 12, 2022 at 08:56:40AM +0100, Frank Scheiner wrote:
    Dear Michael,

    On 12.12.22 08:27, Michael Cree wrote:
    With the usrmerge uploads now depending on a recent libc version Alpha
    is now dead in the water. Nothing can be built. Thus we have to fix
    glibc to continue building.

    I am not prepared to fix ev4 issues so if no one else is prepared to
    fix them then without a architecture baseline raise this is the end
    of Alpha on Debian Ports.

    I'm not sure I fully understand the issue here:

    See, glibc used to work for alpha up until 2.33 as I read. Then a change
    broke it for alpha with 2.34. Does the respective glibc maintainer for
    alpha (Richard Henderson according to [1]) really have no interest in
    fixing it?

    RTH hasn't had working Alpha hardware for quite some time.

    One of the glibc maintainers did have access to one of my Alphas
    until last year but unfortunately the hosting site is no longer
    prepared to host it so I can no longer make that Alpha available
    to developers.

    Thanks for clarifying.

    So with that glibc Alpha support is rotting fast.

    Many of the other ports (e.g. armel, armhf, i386) have had
    architecture baseline increases in the last few years, and none
    support hardware anywhere near as old as alpha ev4.

    I am no longer personally prepared to support Alpha unless
    the architecture baseline increase is done. I have no
    ev4/ev45 hardware and no longer have any interest in supporting
    them.

    Yeah, I figured that already from your first email today.

    In your email to Adrian you write about BWX capable processors as new
    baseline. So EV56 instead of EV67?

    Cheers,
    Frank

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to All on Mon Dec 12 12:30:01 2022
    On Dec 12, 2022, at 9:27 AM, Michael Cree <mcree@orcon.net.nz> wrote:

    I am not interested in supporting old Alphas without BWX anymore.
    I am drawing the line. Either someone steps up to support non-BWX
    Alpha and promptly fixes glibc or the architecture baseline is
    increased to include BWX (thereby fixing most of the glibc issues).
    Without either of those happening I give up being an Alpha porter
    and switch off my Alpha buildd permanently. I have many other
    interesting projects I could be working on!

    As a compromise, how about we fix the bug, create a final set of CD images for old Alphas, then raise the baseline after having verified it does not break QEMU (both -user and -system)?

    Adrian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to All on Mon Dec 12 19:30:01 2022
    On Dec 12, 2022, at 7:17 PM, Michael Cree <mcree@orcon.net.nz> wrote:

    On Mon, Dec 12, 2022 at 12:24:59PM +0100, John Paul Adrian Glaubitz wrote:


    On Dec 12, 2022, at 9:27 AM, Michael Cree <mcree@orcon.net.nz> wrote:

    I am not interested in supporting old Alphas without BWX anymore.
    I am drawing the line. Either someone steps up to support non-BWX
    Alpha and promptly fixes glibc or the architecture baseline is
    increased to include BWX (thereby fixing most of the glibc issues).
    Without either of those happening I give up being an Alpha porter
    and switch off my Alpha buildd permanently. I have many other
    interesting projects I could be working on!

    As a compromise, how about we fix the bug, create a final set of CD
    images for old Alphas, then raise the baseline after having verified
    it does not break QEMU (both -user and -system)?

    You fix the bug then. I'm not interested so there is no "we" in this.

    Please don’t be so negative.

    We should be able to have a discussion on this topic without such sentiments.

    There are valid arguments for both sides, so it’s not helpful to lead a discussion like this.

    Adrian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Cree@21:1/5 to John Paul Adrian Glaubitz on Mon Dec 12 19:20:01 2022
    On Mon, Dec 12, 2022 at 12:24:59PM +0100, John Paul Adrian Glaubitz wrote:


    On Dec 12, 2022, at 9:27 AM, Michael Cree <mcree@orcon.net.nz> wrote:

    I am not interested in supporting old Alphas without BWX anymore.
    I am drawing the line. Either someone steps up to support non-BWX
    Alpha and promptly fixes glibc or the architecture baseline is
    increased to include BWX (thereby fixing most of the glibc issues).
    Without either of those happening I give up being an Alpha porter
    and switch off my Alpha buildd permanently. I have many other
    interesting projects I could be working on!

    As a compromise, how about we fix the bug, create a final set of CD
    images for old Alphas, then raise the baseline after having verified
    it does not break QEMU (both -user and -system)?

    You fix the bug then. I'm not interested so there is no "we" in this.

    Cheers,
    Michael.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Cree@21:1/5 to John Paul Adrian Glaubitz on Mon Dec 12 20:50:01 2022
    On Mon, Dec 12, 2022 at 07:24:06PM +0100, John Paul Adrian Glaubitz wrote:
    On Dec 12, 2022, at 7:17 PM, Michael Cree <mcree@orcon.net.nz> wrote:

    On Mon, Dec 12, 2022 at 12:24:59PM +0100, John Paul Adrian Glaubitz wrote:


    On Dec 12, 2022, at 9:27 AM, Michael Cree <mcree@orcon.net.nz> wrote: >>>
    I am not interested in supporting old Alphas without BWX anymore.
    I am drawing the line. Either someone steps up to support non-BWX
    Alpha and promptly fixes glibc or the architecture baseline is
    increased to include BWX (thereby fixing most of the glibc issues).
    Without either of those happening I give up being an Alpha porter
    and switch off my Alpha buildd permanently. I have many other
    interesting projects I could be working on!

    As a compromise, how about we fix the bug, create a final set of CD
    images for old Alphas, then raise the baseline after having verified
    it does not break QEMU (both -user and -system)?

    You fix the bug then. I'm not interested so there is no "we" in this.

    Please don’t be so negative.

    We should be able to have a discussion on this topic without such sentiments.

    There are valid arguments for both sides, so it’s not helpful to lead a discussion like this.

    I had wanted to do this years ago. Every time I have raised it someone
    has protested. The discussion has been had again and again and I am no
    longer interested in it. The result of the discussion is that it is I
    who ends up fixing the problems arising from supporting EV4/EV45.

    The bottom line is that I am not prepared to support EV4/EV45 anymore.
    This is not being negative. This is me being honest about the fact
    that I have too limited time and many other projects that I want to
    work on.

    Either the arch baseline is raised to something that is easier to
    maintain (which, frankly, I think is essential if the Alpha port is to
    survive any longer), someone else steps up to fix the brokenness that
    arises from non-atomic multi-cpu-instruction 8-bit and 16-bit memory
    accesses, or I bail out of maintaining Debian-Ports Alpha.

    Cheers,
    Michael.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Michael Cree on Tue Dec 13 06:20:01 2022
    Hello!

    On 12/12/22 20:45, Michael Cree wrote:
    Either the arch baseline is raised to something that is easier to
    maintain (which, frankly, I think is essential if the Alpha port is to survive any longer), someone else steps up to fix the brokenness that
    arises from non-atomic multi-cpu-instruction 8-bit and 16-bit memory accesses, or I bail out of maintaining Debian-Ports Alpha.

    So what baseline do we want? Would EV56 be sufficient? Because that would
    still work with my AlphaStation 433au and XP1000 and gets us BWX.

    I don't want to use something like EV67 as I think that would limit the
    usable hardware too much. I guess I can live with dropping EV4 since NetBSD
    and Gentoo would still run on these.

    I am still interested in fixing the glibc bug and will work on bisecting it.

    If EV56 is the baseline we can agree on, please go ahead and rebuild glibc
    and gcc using this baseline.

    Thanks,
    Adrian

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Cree@21:1/5 to John Paul Adrian Glaubitz on Tue Dec 13 08:50:01 2022
    On Tue, Dec 13, 2022 at 06:15:16AM +0100, John Paul Adrian Glaubitz wrote:
    Hello!

    On 12/12/22 20:45, Michael Cree wrote:
    Either the arch baseline is raised to something that is easier to
    maintain (which, frankly, I think is essential if the Alpha port is to survive any longer), someone else steps up to fix the brokenness that arises from non-atomic multi-cpu-instruction 8-bit and 16-bit memory accesses, or I bail out of maintaining Debian-Ports Alpha.

    So what baseline do we want? Would EV56 be sufficient? Because that would still work with my AlphaStation 433au and XP1000 and gets us BWX.

    Yes. The first extension added is the byte-word extension which came
    in with EV56. That provides CPU instructions for byte and word (16-bit)
    memory accesses. That is the most important one: possibly a third of
    the bugs in the repository extend from non-atomic byte and word
    accesses. The kernel developers have expressed a view that they would
    like to assume on all arches that byte and word memory accesses are
    atomic and the only architecture that is holding them back from that
    assumption are old Alphas without BWX. There is an old open bug on
    gcc related to the non-atomic memory accesses of old Alphas and that
    one is basically cannot fix.

    If we went to BWX (i.e. EV56) then as you say that means the personal workstations (e.g. PWS433au and PWS500au), which a lot of Alpha users
    have and AlphaStations such as the 433au will still be supported.

    I don't want to use something like EV67 as I think that would limit the usable hardware too much.

    Yes, that's the problem going fully to EV67. The CPU extensions we
    would get are MVI (motion video instructions) that came in with
    PCA56, CIX (count integer instructions with the like of counting
    trailing zeros) that came in with EV67 and FIX (floating point
    extensions primarily for efficient conversion between float and
    integer and a sqrt instruction) with EV6, but these are nowhere
    near as important as BWX in terms of reducing bug fixing workload
    in maintaining the port.

    I guess I can live with dropping EV4 since NetBSD
    and Gentoo would still run on these.

    Gentoo has the advantage (and disadvantage) of compiling from
    source so one can optimise their own installation for their
    hardware.

    I am still interested in fixing the glibc bug and will work on bisecting it.

    If EV56 is the baseline we can agree on, please go ahead and rebuild glibc and gcc using this baseline.

    I am currently building gcc-12 to default to EV56/BWX. In the test
    suite now so probably won't be finished till tomorrow. Then I will try building latest glibc (2.36-6) with that gcc. I suspect there will
    still be a couple of test suite failures so there will probably be
    a further delay before I have it ready to upload to the repository. In
    any case I will give fair warning before I do.

    Cheers,
    Michael.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Michael Cree on Tue Dec 13 10:00:01 2022
    Hi!

    On 12/13/22 08:44, Michael Cree wrote:
    So what baseline do we want? Would EV56 be sufficient? Because that would
    still work with my AlphaStation 433au and XP1000 and gets us BWX.

    Yes. The first extension added is the byte-word extension which came
    in with EV56. That provides CPU instructions for byte and word (16-bit) memory accesses. That is the most important one: possibly a third of
    the bugs in the repository extend from non-atomic byte and word
    accesses. The kernel developers have expressed a view that they would
    like to assume on all arches that byte and word memory accesses are
    atomic and the only architecture that is holding them back from that assumption are old Alphas without BWX. There is an old open bug on
    gcc related to the non-atomic memory accesses of old Alphas and that
    one is basically cannot fix.

    If we went to BWX (i.e. EV56) then as you say that means the personal workstations (e.g. PWS433au and PWS500au), which a lot of Alpha users
    have and AlphaStations such as the 433au will still be supported.

    Thanks for the confirmation and clarification!

    I don't want to use something like EV67 as I think that would limit the
    usable hardware too much.

    Yes, that's the problem going fully to EV67. The CPU extensions we
    would get are MVI (motion video instructions) that came in with
    PCA56, CIX (count integer instructions with the like of counting
    trailing zeros) that came in with EV67 and FIX (floating point
    extensions primarily for efficient conversion between float and
    integer and a sqrt instruction) with EV6, but these are nowhere
    near as important as BWX in terms of reducing bug fixing workload
    in maintaining the port.

    OK, so EV56 sounds like a very good compromise. I guess we can still
    keep the -ev67 glibc package for people with these CPUs.

    I guess I can live with dropping EV4 since NetBSD
    and Gentoo would still run on these.

    Gentoo has the advantage (and disadvantage) of compiling from
    source so one can optimise their own installation for their
    hardware.

    Yes, of couse.

    I am still interested in fixing the glibc bug and will work on bisecting it. >>
    If EV56 is the baseline we can agree on, please go ahead and rebuild glibc >> and gcc using this baseline.

    I am currently building gcc-12 to default to EV56/BWX. In the test
    suite now so probably won't be finished till tomorrow. Then I will try building latest glibc (2.36-6) with that gcc. I suspect there will
    still be a couple of test suite failures so there will probably be
    a further delay before I have it ready to upload to the repository. In
    any case I will give fair warning before I do.

    Feel free to open bugs against glibc and gcc to request the raise of the baseline.

    Adrian

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to All on Tue Dec 13 10:40:01 2022
    SGkgZ3V5cywNCg0KT24gMTMuMTIuMjIgMDY6MTUsIEpvaG4gUGF1bCBBZHJpYW4gR2xhdWJp dHogd3JvdGU6DQo+IFsuLi5dDQo+IEkgYW0gc3RpbGwgaW50ZXJlc3RlZCBpbiBmaXhpbmcg dGhlIGdsaWJjIGJ1ZyBhbmQgd2lsbCB3b3JrIG9uIGJpc2VjdGluZyANCj4gaXQuDQoNCkkg eWVzdGRlcmRheSBkaWQgZ2l2ZSB0aGF0IGEgdHJ5IG9uIGEgRFMxNSwgYnV0IGl0IHRvb2sg YWxyZWFkeSBob3VycyB0byANCmdldCBnbGliYyAyLjMzIGNvbXBpbGVkLg0KDQpEdXJpbmcg dGhpcyBjb21waWxhdGlvbiBJIGdvdCA0IHNlZ2ZhdWx0cyBmcm9tIHRoZSBjb21waWxlciAo Z2NjLTEyKSBhbmQgDQphICJnY2M6IGludGVybmFsIGNvbXBpbGVyIGVycm9yOiBBYm9ydGVk IHNpZ25hbCB0ZXJtaW5hdGVkIHByb2dyYW0gY2MxIi4gDQpJZiB5b3UgYXJlIGludGVyZXN0 ZWQgaW4gdGhlIGRldGFpbHMsIEkgaGF2ZSBhbGwgdGhlIGVycm9yIG1lc3NhZ2VzIA0KYXZh aWxhYmxlLg0KDQpUaGlzIHdlbnQgb24gZHVyaW5nIGBtYWtlIHRlc3RgIHdpdGggYW5vdGhl ciBzZWdmYXVsdCBhbmQgdGhpcyBvbmUgaGVyZSANCmFmdGVyIG1vcmUgdGhhbiAyIGhvdXJz IG9mIHByb2Nlc3Npbmc6DQoNCmBgYA0Kcm9vdEBkczE1Oi9zcnYvc3RvcmFnZS9idWlsZC9n bGliYy0yLjMzIyB0aW1lIG1ha2UgdGVzdA0KWy4uLl0NCmcrKyB0c3QtdGhyZWFkX2xvY2Fs MS5jYyAtYyAtSS9zcnYvc3RvcmFnZS9idWlsZC9nbGliYy0yLjMzLyAgLWcgLU8yIA0KLVdh bGwgLVd3cml0ZS1zdHJpbmdzIC1XdW5kZWYgLWZtZXJnZS1hbGwtY29uc3RhbnRzIC1mcm91 bmRpbmctbWF0aCANCi1mbm8tc3RhY2stcHJvdGVjdG9yIC1tbG9uZy1kb3VibGUtMTI4IC1t aWVlZSAtbWZwLXJvdW5kaW5nLW1vZGU9ZCANCi1zdGQ9Z251KysxMSAgICAgLUkuLi9pbmNs dWRlIC1JL3Nydi9zdG9yYWdlL2J1aWxkL2dsaWJjLTIuMzMvbnB0bCANCi1JL3Nydi9zdG9y YWdlL2J1aWxkL2dsaWJjLTIuMzMgIC1JLi4vc3lzZGVwcy91bml4L3N5c3YvbGludXgvYWxw aGEvZnB1IA0KLUkuLi9zeXNkZXBzL2FscGhhL2ZwdSAgLUkuLi9zeXNkZXBzL3VuaXgvc3lz di9saW51eC9hbHBoYSANCi1JLi4vc3lzZGVwcy9hbHBoYS9ucHRsICAtSS4uL3N5c2RlcHMv dW5peC9zeXN2L2xpbnV4L3dvcmRzaXplLTY0IA0KLUkuLi9zeXNkZXBzL2llZWU3NTQvbGRi bC02NC0xMjggIC1JLi4vc3lzZGVwcy9pZWVlNzU0L2xkYmwtb3B0IA0KLUkuLi9zeXNkZXBz L3VuaXgvc3lzdi9saW51eC9pbmNsdWRlIC1JLi4vc3lzZGVwcy91bml4L3N5c3YvbGludXgg DQotSS4uL3N5c2RlcHMvbnB0bCAgLUkuLi9zeXNkZXBzL3B0aHJlYWQgIC1JLi4vc3lzZGVw cy9nbnUgDQotSS4uL3N5c2RlcHMvdW5peC9pbmV0ICAtSS4uL3N5c2RlcHMvdW5peC9zeXN2 ICAtSS4uL3N5c2RlcHMvdW5peC9hbHBoYSANCi1JLi4vc3lzZGVwcy91bml4ICAtSS4uL3N5 c2RlcHMvcG9zaXggIC1JLi4vc3lzZGVwcy9hbHBoYSANCi1JLi4vc3lzZGVwcy93b3Jkc2l6 ZS02NCAgLUkuLi9zeXNkZXBzL2llZWU3NTQvbGRibC0xMjggDQotSS4uL3N5c2RlcHMvaWVl ZTc1NC9kYmwtNjQgIC1JLi4vc3lzZGVwcy9pZWVlNzU0L2ZsdC0zMiANCi1JLi4vc3lzZGVw cy9pZWVlNzU0ICAtSS4uL3N5c2RlcHMvZ2VuZXJpYyAgLUkuLiAtSS4uL2xpYmlvIC1JLiAN Ci1EX0xJQkNfUkVFTlRSQU5UIC1pbmNsdWRlIC9zcnYvc3RvcmFnZS9idWlsZC9nbGliYy0y LjMzL2xpYmMtbW9kdWxlcy5oIA0KLURNT0RVTEVfTkFNRT10ZXN0c3VpdGUgLWluY2x1ZGUg Li4vaW5jbHVkZS9saWJjLXN5bWJvbHMuaCANCi1EVE9QX05BTUVTUEFDRT1nbGliYyAtbyAN Ci9zcnYvc3RvcmFnZS9idWlsZC9nbGliYy0yLjMzL25wdGwvdHN0LXRocmVhZF9sb2NhbDEu byAtTUQgLU1QIC1NRiANCi9zcnYvc3RvcmFnZS9idWlsZC9nbGliYy0yLjMzL25wdGwvdHN0 LXRocmVhZF9sb2NhbDEuby5kdCAtTVQgDQovc3J2L3N0b3JhZ2UvYnVpbGQvZ2xpYmMtMi4z My9ucHRsL3RzdC10aHJlYWRfbG9jYWwxLm8NCnRzdC10aHJlYWRfbG9jYWwxLmNjOiBJbiBm dW5jdGlvbiDigJhpbnQgZG9fdGVzdCgp4oCZOg0KdHN0LXRocmVhZF9sb2NhbDEuY2M6MTc3 OjU6IGVycm9yOiB2YXJpYWJsZSDigJhzdGQ6OmFycmF5PHN0ZDo6cGFpcjxjb25zdCANCmNo YXIqLCBzdGQ6OmZ1bmN0aW9uPHZvaWQodm9pZCogKCopKHZvaWQqKSk+ID4sIDI+IGRvX3Ro cmVhZF9Y4oCZIGhhcyANCmluaXRpYWxpemVyIGJ1dCBpbmNvbXBsZXRlIHR5cGUNCiAgIDE3 NyB8ICAgICBkb190aHJlYWRfWA0KICAgICAgIHwgICAgIF5+fn5+fn5+fn5+DQp0c3QtdGhy ZWFkX2xvY2FsMS5jYzogQXQgZ2xvYmFsIHNjb3BlOg0KdHN0LXRocmVhZF9sb2NhbDEuY2M6 MTMzOjE6IHdhcm5pbmc6IOKAmHZvaWQqIHRocmVhZF93aXRoX2FjY2Vzcyh2b2lkKinigJkg DQpkZWZpbmVkIGJ1dCBub3QgdXNlZCBbLVd1bnVzZWQtZnVuY3Rpb25dDQogICAxMzMgfCB0 aHJlYWRfd2l0aF9hY2Nlc3MgKHZvaWQgKikNCiAgICAgICB8IF5+fn5+fn5+fn5+fn5+fn5+ fg0KdHN0LXRocmVhZF9sb2NhbDEuY2M6MTI3OjE6IHdhcm5pbmc6IOKAmHZvaWQqIA0KdGhy ZWFkX3dpdGhvdXRfYWNjZXNzKHZvaWQqKeKAmSBkZWZpbmVkIGJ1dCBub3QgdXNlZCBbLVd1 bnVzZWQtZnVuY3Rpb25dDQogICAxMjcgfCB0aHJlYWRfd2l0aG91dF9hY2Nlc3MgKHZvaWQg KikNCiAgICAgICB8IF5+fn5+fn5+fn5+fn5+fn5+fn5+fg0KbWFrZVsyXTogKioqIFsuLi9v LWl0ZXJhdG9yLm1rOjk6IA0KL3Nydi9zdG9yYWdlL2J1aWxkL2dsaWJjLTIuMzMvbnB0bC90 c3QtdGhyZWFkX2xvY2FsMS5vXSBFcnJvciAxDQptYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9y eSAnL3Nydi9zdG9yYWdlL2dsaWJjL25wdGwnDQptYWtlWzFdOiAqKiogW01ha2VmaWxlOjQ3 OTogbnB0bC90ZXN0c10gRXJyb3IgMg0KbWFrZVsxXTogTGVhdmluZyBkaXJlY3RvcnkgJy9z cnYvc3RvcmFnZS9nbGliYycNCm1ha2U6ICoqKiBbTWFrZWZpbGU6OTogY2hlY2tdIEVycm9y IDINCg0KcmVhbAkxMjltMy45NDBzDQp1c2VyCTEwNG0yNS40NDFzDQpzeXMJMTFtMzYuNjEx cw0KYGBgDQoNCi4uLmFmdGVyIHdoaWNoIEkgc3RvcHBlZC4gSSBkaWQgdXNlIGAtLWRpc2Fi bGUtd2Vycm9yYCBkdXJpbmcgdGhlIA0KY29uZmlndXJlIHN0ZXAsIGJ1dCBtYXliZSB0aGlz IGlzIG5vdCBlbm91Z2guIE9UT0ggaXQncyBvbmx5IGEgd2FybmluZyANCnNvIHdoeSBkb2Vz IGl0IGVycj8gQWgsIEkgc2VlIGl0IGAtV3VuZGVmYCBpcyBzZXQuIEknbGwgaGF2ZSBhIGxv b2sgd2hhdCANCnRoZSBidWlsZGRzIHVzZSBmb3IgdGhlIGNvbmZpZ3VyZSBzdGVwLg0KDQpU b2RheSBJJ2xsIGFsc28gZ2l2ZSBpdCBhbm90aGVyIHRyeSwgYnV0IHdpdGggZ2NjLTExIHRo aXMgdGltZSAtIGp1c3QgaW4gDQpjYXNlIHNvbWV0aGluZyBpcyB3cm9uZyB3aXRoIGdjYy0x MiAtIGJ1dCBmcmFua2x5IEkgZG9uJ3QgdGhpbmsgdGhpcyANCmdvZXMgYW55d2hlcmUgb24g dGhlIERTMTU6DQoNCkV2ZW4gd2l0aCBhIERTMjUgSSBoYXZlIGF2YWlsYWJsZSBoZXJlIEkg Y2FuIG9ubHkgc3BlZWQgdXAgdGhlIA0KY29tcGlsYXRpb24gYW5kIGl0IHRha2VzIGFscmVh ZHkgbW9yZSB0aGFuIHR3aWNlIHRoZSBwb3dlciBvZiB0aGUgRFMxNSwgDQpzbyBub3RoaW5n IGdhaW5lZC4gTXkgRVM0NXMgYXJlIGluIGNvbGQgc3RvcmFnZSBhbmQgSSBkb24ndCBkYXJl IHRvIA0Kc3RhcnQgdGhlbSB1cCBpbiBzdWNoIGEgbG93IHRlbXBlcmF0dXJlIGVudmlyb25t ZW50Lg0KDQpTdW1tYXJpemluZyBpdCwgSSdkIGJlIGdyYXRlZnVsIGlmIHNvbWVvbmUgY291 bGQgZG8gdGhlIGJpc2VjdGluZyBvbiBvbmUgDQpvZiB0aGUgYnVpbGRkcyBvciBkZXZlbG9w ZXIgbWFjaGluZXMuDQoNCkNoZWVycywNCkZyYW5rDQoNCg0K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to All on Tue Dec 13 11:00:01 2022
    SGkgYWdhaW4sDQoNCmp1c3Qgd2FudGVkIHRvIGNsYXJpZnkgc29tZXRoaW5nIEkgc2F3IGlu IHRoZSBidWlsZCBsb2dzIGZyb20gdGhlIA0KYnVpbGRkcyAtIGltYWdvIHRvIGJlIHNwZWNp ZmljLg0KDQpPbiAxMy4xMi4yMiAxMDozMywgRnJhbmsgU2NoZWluZXIgd3JvdGU6DQo+IFsu Li5dDQo+IFN1bW1hcml6aW5nIGl0LCBJJ2QgYmUgZ3JhdGVmdWwgaWYgc29tZW9uZSBjb3Vs ZCBkbyB0aGUgYmlzZWN0aW5nIG9uIG9uZSANCj4gb2YgdGhlIGJ1aWxkZHMgb3IgZGV2ZWxv cGVyIG1hY2hpbmVzLg0KDQpBY2NvcmRpbmcgdG8gdGhlIGxvZ3Mgb24gWzFdIGFuZCBbMl0s IHRoZSBtYWNoaW5lIHNlZW1zIHRvIHJ1biB3L28gQmNhY2hlOg0KDQpgYGANCnVuYW1lIC1h DQpMaW51eCBpbWFnbyA1LjguMTgtdGl0YW4tcDErICM2MyBTTVAgU2F0IEphbiA4IDE2OjE4 OjAxIE5aRFQgMjAyMiBhbHBoYSANCkdOVS9MaW51eA0KDQppZiBbIC1mIC9wcm9jL2NwdWlu Zm8gXSA7IHRoZW4gY2F0IC9wcm9jL2NwdWluZm8gOyBmaQ0KY3B1CQkJOiBBbHBoYQ0KY3B1 IG1vZGVsCQk6IEVWNjhDQg0KY3B1IHZhcmlhdGlvbgkJOiA3DQpjcHUgcmV2aXNpb24JCTog MA0KY3B1IHNlcmlhbCBudW1iZXIJOiBKQTQ0OTAwMTY1DQpzeXN0ZW0gdHlwZQkJOiBUaXRh bg0Kc3lzdGVtIHZhcmlhdGlvbgk6IFByaXZhdGVlcg0Kc3lzdGVtIHJldmlzaW9uCQk6IDAN CnN5c3RlbSBzZXJpYWwgbnVtYmVyCTogQVk1MDkwMTAyMw0KY3ljbGUgZnJlcXVlbmN5IFtI el0JOiAxMjUwMDAwMDAwDQp0aW1lciBmcmVxdWVuY3kgW0h6XQk6IDEwMjQuMDANCnBhZ2Ug c2l6ZSBbYnl0ZXNdCTogODE5Mg0KcGh5cy4gYWRkcmVzcyBiaXRzCTogNDQNCm1heC4gYWRk ci4gc3BhY2UgIwk6IDI1NQ0KQm9nb01JUFMJCTogMjQ4MC45Mg0Ka2VybmVsIHVuYWxpZ25l ZCBhY2MJOiAwIChwYz0wLHZhPTApDQp1c2VyIHVuYWxpZ25lZCBhY2MJOiAzMzg4OTc2MTIg KHBjPTIwMDAwMGUxMDBjLHZhPTEyMDBlNzFjYykNCnBsYXRmb3JtIHN0cmluZwkJOiBBbHBo YVNlcnZlciBFUzQ1IE1vZGVsIDFCDQpjcHVzIGRldGVjdGVkCQk6IDMNCmNwdXMgYWN0aXZl CQk6IDMNCmNwdSBhY3RpdmUgbWFzawkJOiAwMDAwMDAwMDAwMDAwMDA3DQpMMSBJY2FjaGUJ CTogNjRLLCAyLXdheSwgNjRiIGxpbmUNCkwxIERjYWNoZQkJOiA2NEssIDItd2F5LCA2NGIg bGluZQ0KTDIgY2FjaGUJCTogbi9hDQpMMyBjYWNoZQkJOiBuL2ENCmBgYA0KDQpbMV06IA0K aHR0cHM6Ly9idWlsZGQuZGViaWFuLm9yZy9zdGF0dXMvZmV0Y2gucGhwP3BrZz1nbGliYyZh cmNoPWFscGhhJnZlcj0yLjM0LTgmc3RhbXA9MTY2Mjk2MzYyOCZyYXc9MA0KDQpbMl06IA0K aHR0cHM6Ly9idWlsZGQuZGViaWFuLm9yZy9zdGF0dXMvZmV0Y2gucGhwP3BrZz1nbGliYyZh cmNoPWFscGhhJnZlcj0yLjM2LTQmc3RhbXA9MTY2NzYwNzMwNiZyYXc9MA0KDQpTZWUgIm4v YSIgZm9yIHRoZSBMMiBjYWNoZSBsaW5lPyBJcyB0aGF0ICgxKSBhbiBlcnJvciBpbiB0aGUg a2VybmVsIG5vdCANCmJlaW5nIGFibGUgdG8gZGV0ZWN0IHRoZSAxNiBNaUIgQmNhY2hlIG9m IHRoZSAxMjUwIE1IeiBwcm9jZXNzb3IgbW9kdWxlcyANCm9yICgyKSBpcyB0aGlzIG1hY2hp bmUgcmVhbGx5IHJ1bm5pbmcgdy9vIGFjdGl2ZSBCY2FjaGU/DQoNCklmICgyKSBJIGRvbid0 IGtub3cgaG93IG11Y2ggZWZmZWN0IHRoaXMgaGFzIG9uIGNvbXBpbGF0aW9uLCBidXQgSSAN CnJlY2VudGx5IGhhZCBhIHNpbWlsYXIgaXNzdWUgd2l0aCB0aGUgRFMxNSAtIGkuZS4gQmNh Y2hlIG5vdCBhY3RpdmF0ZWQgLSANCmFuZCBjb3VsZCBzZWUgYSBub3RpY2FibGUgZGlmZmVy ZW5jZSBpbiBwZXJmb3JtYW5jZSBmb3IgZS5nLiBgN3phIGJgIA0KYW5kIGBvcGVuc3NsIHNw ZWVkIC1lbGFwc2VkYCB3aGVuIGNvbXBhcmVkIHRvIHJ1bnMgd2l0aCBhY3RpdmUgQmNhY2hl IGxhdGVyLg0KDQpUaG91Z2ggSSBmb3VuZCBhIHNvbHV0aW9uIGZvciB0aGUgRFMxNSwgSSBk aWRuJ3QgZmluZCBhbnl0aGluZyByZWxhdGVkIA0KeWV0IGZvciBhbiBFUzQ1Lg0KDQpCdXQg bWF5YmUgdGhpcyBpcyBqdXN0IGEga2VybmVsIGJ1ZyBhbmQgdGhlIEJjYWNoZSBpcyBhY3Rp dmUgZGVzcGl0ZSANCnRoYXQgbWVzc2FnZS4gWW91IGNhbiBjaGVjayBpbiBTUk0gd2l0aCBg c2hvdyBjb25maWcgfCBtb3JlYDoNCg0KYGBgDQogPj4+c2hvdyBjb25maWcgfCBtb3JlDQog ICAgICAgICAgICAgICAgICAgICAgICAgICBocCBBbHBoYVN0YXRpb24gRFMxNQ0KWy4uLl0N ClByb2Nlc3NvcnMNCkNQVSAwICAgICAgICAgICBBbHBoYSBFVjY4Q0IgcGFzcyA0LjAgMTAw MCBNSHogIDJNQiBCY2FjaGUNClsuLi5dDQpgYGANCg0KSWYgeW91IHNlZSAiME1CIEJjYWNo ZSIgc29tZXRoaW5nIGlzIHdyb25nLg0KDQpBbHRlcm5hdGl2ZWx5IHRoZSBSTUMgc2hvdWxk IGFsc28gYmUgYWJsZSB0byB0ZWxsIHlvdSB0aGUgc3RhdGUgb2YgdGhlIA0KcHJvY2Vzc29y cyAodXNpbmcgdGhlIGBjcHVgIGNvbW1hbmQ6DQoNCmBgYA0KUk1DPmNwdQ0K77+9MDsxbQ0K Q1BVIFBvd2VydXAgU3RhdHVzIFRyYW5zbGF0aW9uDQrvv70wbQ0KRVY2IEJJU1Q6IFBBU1MN CkNQVSBJRDogMCAgIChwcmltYXJ5KQ0KU1RSIFRlc3Q6IFBBU1MNCkNTQyBUZXN0OiBQQVNT DQpQQ0hJUDAgVGVzdDogUEFTUw0KRElNeCBUZXN0OiBQQVNTDQpUSUcgQnVzIFRlc3Q6IFBB U1MNCkRQUiBUZXN0OiBTVEFSVEVEIC0gUEFTUw0KQ1BVIFNwZWVkIFRlc3Q6IFBBU1MgLSAx MDAwTUh6DQpTUk9NIFBvd2VyLU9uIFRpbWU6IDEyLTEzLTQyIDA5OjQ1OjM2DQpTUk9NIFBv d2VyLU9uIEVycm9yOiBObyBlcnJvcg0KU3lzdGVtIEJ1cyBTcGVlZDogMTI1TUh6DQpMYXN0 IFN5bmNoIFN0YXRlIFRlc3Q6IFBBU1MNCkJjYWNoZSBTaXplOiAyTUINCmBgYA0KDQopLiBU aG91Z2ggSSdtIG5vdCBzdXJlIGhvdyB0aGlzIHdpbGwgbG9vayBmb3IgbXV0bGlwbGUgcHJv Y2Vzc29ycy4NCg0KQ2hlZXJzLA0KRnJhbmsNCg==

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to All on Tue Dec 13 11:00:01 2022
    SGVsbG8hDQoNCk9uIDEyLzEzLzIyIDEwOjMzLCBGcmFuayBTY2hlaW5lciB3cm90ZToNCj4g SGkgZ3V5cywNCj4gDQo+IE9uIDEzLjEyLjIyIDA2OjE1LCBKb2huIFBhdWwgQWRyaWFuIEds YXViaXR6IHdyb3RlOg0KPj4gWy4uLl0NCj4+IEkgYW0gc3RpbGwgaW50ZXJlc3RlZCBpbiBm aXhpbmcgdGhlIGdsaWJjIGJ1ZyBhbmQgd2lsbCB3b3JrIG9uIGJpc2VjdGluZyBpdC4NCj4g DQo+IEkgeWVzdGRlcmRheSBkaWQgZ2l2ZSB0aGF0IGEgdHJ5IG9uIGEgRFMxNSwgYnV0IGl0 IHRvb2sgYWxyZWFkeSBob3VycyB0byBnZXQgZ2xpYmMgMi4zMyBjb21waWxlZC4NCj4gDQo+ IER1cmluZyB0aGlzIGNvbXBpbGF0aW9uIEkgZ290IDQgc2VnZmF1bHRzIGZyb20gdGhlIGNv bXBpbGVyIChnY2MtMTIpIGFuZCBhICJnY2M6IGludGVybmFsIGNvbXBpbGVyDQo+IGVycm9y OiBBYm9ydGVkIHNpZ25hbCB0ZXJtaW5hdGVkIHByb2dyYW0gY2MxIi4gSWYgeW91IGFyZSBp bnRlcmVzdGVkIGluIHRoZSBkZXRhaWxzLCBJIGhhdmUgYWxsIHRoZQ0KPiBlcnJvciBtZXNz YWdlcyBhdmFpbGFibGUuDQoNCklzIHRoYXQgZ2xpYmMgZnJvbSB1cHN0cmVhbSBvciB0aGUg RGViaWFuIHBhY2thZ2U/DQoNCkFsc28sIGlzIHRoZSBtYWNoaW5lJ3MgbWVtb3J5IGtub3du IHRvIGJlIGdvb2Q/IFBsZWFzZSBtYWtlIHN1cmUgdG8gdGVzdCBpdC4NCg0KPiBUaGlzIHdl bnQgb24gZHVyaW5nIGBtYWtlIHRlc3RgIHdpdGggYW5vdGhlciBzZWdmYXVsdCBhbmQgdGhp cyBvbmUgaGVyZSBhZnRlciBtb3JlIHRoYW4gMiBob3VycyBvZiBwcm9jZXNzaW5nOg0KPiAN Cj4gYGBgDQo+IHJvb3RAZHMxNTovc3J2L3N0b3JhZ2UvYnVpbGQvZ2xpYmMtMi4zMyMgdGlt ZSBtYWtlIHRlc3QNCj4gWy4uLl0NCj4gZysrIHRzdC10aHJlYWRfbG9jYWwxLmNjIC1jIC1J L3Nydi9zdG9yYWdlL2J1aWxkL2dsaWJjLTIuMzMvICAtZyAtTzIgLVdhbGwgLVd3cml0ZS1z dHJpbmdzIC1XdW5kZWYgLWZtZXJnZS1hbGwtY29uc3RhbnRzIC1mcm91bmRpbmctbWF0aCAt Zm5vLXN0YWNrLXByb3RlY3RvciAtbWxvbmctZG91YmxlLTEyOCAtbWllZWUgLW1mcC1yb3Vu ZGluZy1tb2RlPWQgLXN0ZD1nbnUrKzExICAgICAtSS4uL2luY2x1ZGUgLUkvc3J2L3N0b3Jh Z2UvYnVpbGQvZ2xpYmMtMi4zMy9ucHRsIC1JL3Nydi9zdG9yYWdlL2J1aWxkL2dsaWJjLTIu MzMgIC1JLi4vc3lzZGVwcy91bml4L3N5c3YvbGludXgvYWxwaGEvZnB1IC1JLi4vc3lzZGVw cy9hbHBoYS9mcHUgIC1JLi4vc3lzZGVwcy91bml4L3N5c3YvbGludXgvYWxwaGEgLUkuLi9z eXNkZXBzL2FscGhhL25wdGwgIC1JLi4vc3lzZGVwcy91bml4L3N5c3YvbGludXgvd29yZHNp emUtNjQgLUkuLi9zeXNkZXBzL2llZWU3NTQvbGRibC02NC0xMjggIC1JLi4vc3lzZGVwcy9p ZWVlNzU0L2xkYmwtb3B0IC1JLi4vc3lzZGVwcy91bml4L3N5c3YvbGludXgvaW5jbHVkZSAt SS4uL3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4IC1JLi4vc3lzZGVwcy9ucHRsICAtSS4uL3N5 c2RlcHMvcHRocmVhZCAgLUkuLi9zeXNkZXBzL2dudSAtSS4uL3N5c2RlcHMvdW5peC9pbmV0 ICAtSS4uL3N5c2RlcHMvdW5peC9zeXN2ICAtSS4uL3N5c2RlcHMvdW5peC9hbHBoYSAtSS4u L3N5c2RlcHMvdW5peCAgLUkuLi9zeXNkZXBzL3Bvc2l4ICAtSS4uL3N5c2RlcHMvYWxwaGEg LUkuLi9zeXNkZXBzL3dvcmRzaXplLTY0ICAtSS4uL3N5c2RlcHMvaWVlZTc1NC9sZGJsLTEy OCAtSS4uL3N5c2RlcHMvaWVlZTc1NC9kYmwtNjQgIC1JLi4vc3lzZGVwcy9pZWVlNzU0L2Zs dC0zMiAtSS4uL3N5c2RlcHMvaWVlZTc1NCAgLUkuLi9zeXNkZXBzL2dlbmVyaWMgIC1JLi4g LUkuLi9saWJpbyAtSS4gLURfTElCQ19SRUVOVFJBTlQgLWluY2x1ZGUgDQo+IC9zcnYvc3Rv cmFnZS9idWlsZC9nbGliYy0yLjMzL2xpYmMtbW9kdWxlcy5oIC1ETU9EVUxFX05BTUU9dGVz dHN1aXRlIC1pbmNsdWRlIC4uL2luY2x1ZGUvbGliYy1zeW1ib2xzLmggLURUT1BfTkFNRVNQ QUNFPWdsaWJjIC1vIC9zcnYvc3RvcmFnZS9idWlsZC9nbGliYy0yLjMzL25wdGwvdHN0LXRo cmVhZF9sb2NhbDEubyAtTUQgLU1QIC1NRiAvc3J2L3N0b3JhZ2UvYnVpbGQvZ2xpYmMtMi4z My9ucHRsL3RzdC10aHJlYWRfbG9jYWwxLm8uZHQgLU1UIC9zcnYvc3RvcmFnZS9idWlsZC9n bGliYy0yLjMzL25wdGwvdHN0LXRocmVhZF9sb2NhbDEubw0KPiB0c3QtdGhyZWFkX2xvY2Fs MS5jYzogSW4gZnVuY3Rpb24g4oCYaW50IGRvX3Rlc3QoKeKAmToNCj4gdHN0LXRocmVhZF9s b2NhbDEuY2M6MTc3OjU6IGVycm9yOiB2YXJpYWJsZSDigJhzdGQ6OmFycmF5PHN0ZDo6cGFp cjxjb25zdCBjaGFyKiwgc3RkOjpmdW5jdGlvbjx2b2lkKHZvaWQqICgqKSh2b2lkKikpPiA+ LCAyPiBkb190aHJlYWRfWOKAmSBoYXMgaW5pdGlhbGl6ZXIgYnV0IGluY29tcGxldGUgdHlw ZQ0KPiAgICAxNzcgfCAgICAgZG9fdGhyZWFkX1gNCj4gICAgICAgIHwgICAgIF5+fn5+fn5+ fn5+DQo+IHRzdC10aHJlYWRfbG9jYWwxLmNjOiBBdCBnbG9iYWwgc2NvcGU6DQo+IHRzdC10 aHJlYWRfbG9jYWwxLmNjOjEzMzoxOiB3YXJuaW5nOiDigJh2b2lkKiB0aHJlYWRfd2l0aF9h Y2Nlc3Modm9pZCop4oCZIGRlZmluZWQgYnV0IG5vdCB1c2VkIFstV3VudXNlZC1mdW5jdGlv bl0NCj4gICAgMTMzIHwgdGhyZWFkX3dpdGhfYWNjZXNzICh2b2lkICopDQo+ICAgICAgICB8 IF5+fn5+fn5+fn5+fn5+fn5+fg0KPiB0c3QtdGhyZWFkX2xvY2FsMS5jYzoxMjc6MTogd2Fy bmluZzog4oCYdm9pZCogdGhyZWFkX3dpdGhvdXRfYWNjZXNzKHZvaWQqKeKAmSBkZWZpbmVk IGJ1dCBub3QgdXNlZCBbLVd1bnVzZWQtZnVuY3Rpb25dDQo+ICAgIDEyNyB8IHRocmVhZF93 aXRob3V0X2FjY2VzcyAodm9pZCAqKQ0KPiAgICAgICAgfCBefn5+fn5+fn5+fn5+fn5+fn5+ fn4NCj4gbWFrZVsyXTogKioqIFsuLi9vLWl0ZXJhdG9yLm1rOjk6IC9zcnYvc3RvcmFnZS9i dWlsZC9nbGliYy0yLjMzL25wdGwvdHN0LXRocmVhZF9sb2NhbDEub10gRXJyb3IgMQ0KPiBt YWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSAnL3Nydi9zdG9yYWdlL2dsaWJjL25wdGwnDQo+ IG1ha2VbMV06ICoqKiBbTWFrZWZpbGU6NDc5OiBucHRsL3Rlc3RzXSBFcnJvciAyDQo+IG1h a2VbMV06IExlYXZpbmcgZGlyZWN0b3J5ICcvc3J2L3N0b3JhZ2UvZ2xpYmMnDQo+IG1ha2U6 ICoqKiBbTWFrZWZpbGU6OTogY2hlY2tdIEVycm9yIDINCj4gDQo+IHJlYWwgICAgMTI5bTMu OTQwcw0KPiB1c2VyICAgIDEwNG0yNS40NDFzDQo+IHN5cyAgICAxMW0zNi42MTFzDQo+IGBg YA0KPiANCj4gLi4uYWZ0ZXIgd2hpY2ggSSBzdG9wcGVkLiBJIGRpZCB1c2UgYC0tZGlzYWJs ZS13ZXJyb3JgIGR1cmluZyB0aGUgY29uZmlndXJlIHN0ZXAsIGJ1dCBtYXliZSB0aGlzIGlz IG5vdCBlbm91Z2guDQo+IE9UT0ggaXQncyBvbmx5IGEgd2FybmluZyBzbyB3aHkgZG9lcyBp dCBlcnI/IEFoLCBJIHNlZSBpdCBgLVd1bmRlZmAgaXMgc2V0LiBJJ2xsIGhhdmUgYSBsb29r IHdoYXQgdGhlIGJ1aWxkZHMNCj4gdXNlIGZvciB0aGUgY29uZmlndXJlIHN0ZXAuDQo+IA0K PiBUb2RheSBJJ2xsIGFsc28gZ2l2ZSBpdCBhbm90aGVyIHRyeSwgYnV0IHdpdGggZ2NjLTEx IHRoaXMgdGltZSAtIGp1c3QgaW4gY2FzZSBzb21ldGhpbmcgaXMgd3Jvbmcgd2l0aCBnY2Mt MTINCj4gLSBidXQgZnJhbmtseSBJIGRvbid0IHRoaW5rIHRoaXMgZ29lcyBhbnl3aGVyZSBv biB0aGUgRFMxNToNCj4gDQo+IEV2ZW4gd2l0aCBhIERTMjUgSSBoYXZlIGF2YWlsYWJsZSBo ZXJlIEkgY2FuIG9ubHkgc3BlZWQgdXAgdGhlIGNvbXBpbGF0aW9uIGFuZCBpdCB0YWtlcyBh bHJlYWR5IG1vcmUgdGhhbiB0d2ljZQ0KPiB0aGUgcG93ZXIgb2YgdGhlIERTMTUsIHNvIG5v dGhpbmcgZ2FpbmVkLiBNeSBFUzQ1cyBhcmUgaW4gY29sZCBzdG9yYWdlIGFuZCBJIGRvbid0 IGRhcmUgdG8gc3RhcnQgdGhlbSB1cCBpbiBzdWNoDQo+IGEgbG93IHRlbXBlcmF0dXJlIGVu dmlyb25tZW50Lg0KPiANCj4gU3VtbWFyaXppbmcgaXQsIEknZCBiZSBncmF0ZWZ1bCBpZiBz b21lb25lIGNvdWxkIGRvIHRoZSBiaXNlY3Rpbmcgb24gb25lIG9mIHRoZSBidWlsZGRzIG9y IGRldmVsb3BlciBtYWNoaW5lcy4NCg0KWW91IGNvdWxkIGNyb3NzLWNvbXBpbGUgZ2xpYmMu IFRoYXQncyBtb3N0IGxpa2VseSB3aGF0IEkgYW0gZ29pbmcgdG8gZG8uDQoNCkFkcmlhbg0K DQotLSANCiAgLicnYC4gIEpvaG4gUGF1bCBBZHJpYW4gR2xhdWJpdHoNCjogOicgOiAgRGVi aWFuIERldmVsb3Blcg0KYC4gYCcgICBQaHlzaWNpc3QNCiAgIGAtICAgIEdQRzogNjJGRiA4 QTc1IDg0RTAgMjk1NiA5NTQ2ICAwMDA2IDc0MjYgM0IzNyBGNUI1IEY5MTMNCg0K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to John Paul Adrian Glaubitz on Tue Dec 13 11:10:02 2022
    Hi,

    On 13.12.22 10:52, John Paul Adrian Glaubitz wrote:
    [...]
    During this compilation I got 4 segfaults from the compiler (gcc-12)
    and a "gcc: internal compiler
    error: Aborted signal terminated program cc1". If you are interested
    in the details, I have all the
    error messages available.

    Is that glibc from upstream or the Debian package?

    Upstream, I followed [1].

    [1]: https://sourceware.org/glibc/wiki/Testing/Builds

    Also, is the machine's memory known to be good? Please make sure to test
    it.

    I don't know for sure - you never know for software running on the same hardware that's gonna be tested - but the SROM testing didn't show any
    problems at least:

    ```
    ............
    SROM V1.0-0 CPU # 00 @ 1000 MHz
    SROM program starting
    Reloading SROM
    ............
    SROM V1.0-1 CPU # 00 @ 1000 MHz
    System Bus Speed @ 0125 MHz
    SROM program starting
    Bcache data tests in progress
    Bcache address test in progress
    CPU parity and ECC detection in progress
    Bcache ECC data tests in progress
    Bcache TAG lines tests in progress
    Memory sizing in progress
    Memory configuration in progress
    Testing AAR2
    Memory data test in progress
    Memory address test in progress
    Memory pattern test in progress
    Testing AAR0
    Memory data test in progress
    Memory address test in progress
    Memory pattern test in progress
    Memory initialization
    ............Loading console
    Code execution complete (transfer control)
    ```

    I can try to increase the depth of testing - if possible - but I'd
    expect some ECC related messaging for any failures happening and there
    was none on the system console.

    [...]
    Summarizing it, I'd be grateful if someone could do the bisecting on
    one of the buildds or developer machines.

    You could cross-compile glibc. That's most likely what I am going to do.

    Can the testing happen on a different arch, too?

    Cheers,
    Frank

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to John Paul Adrian Glaubitz on Tue Dec 13 17:30:01 2022
    Hi!

    On 12/13/22 10:52, John Paul Adrian Glaubitz wrote:
    You could cross-compile glibc. That's most likely what I am going to do.

    For the record, here's how I am doing it.

    1. Create an alpha chroot on an x86_64 host system using debootstrap
    on a system with qemu-user-static installed.

    # debootstrap --no-check-gpg --arch=alpha unstable /srv/sid-alpha-sbuild http://ftp.ports.debian.org/debian-ports

    (See below for schroot configuration).

    2. Install cross-compiler for alpha as well as build dependencies for glibc:

    # apt install g++-alpha-linux-gnu
    # apt build-dep --arch-only glibc

    3. Cross-compile glibc on x86_64 on host system:

    $ cd /path/to/glibc/
    $ mkdir build && cd build
    $ ../configure --host=alpha-linux-gnu --disable-werror --prefix=/usr --disable-sanity-checks && make -j8

    4. Enter alpha schroot and run the the following command from the build directory:

    (sid-alpha-sbuild)glaubitz@z6:~/glibc-git/build$ LD_LIBRARY_PATH=/home/glaubitz/glibc-git/build /bin/bash

    If the bug is present, this command will segfault:

    Segmentation fault

    Otherwise it will just spawn another bash which can be exited with "exit":

    (sid-alpha-sbuild)glaubitz@z6:~/glibc-git/build$ LD_LIBRARY_PATH=/home/glaubitz/glibc-git/build /bin/bash
    (sid-alpha-sbuild)glaubitz@z6:~/glibc-git/build$
    exit
    (sid-alpha-sbuild)glaubitz@z6:~/glibc-git/build$

    The trick is to share the glibc source directory into the schroot. This is achieved by the following
    two configuration files:

    root@z6:~> cat /etc/schroot/chroot.d/sid-alpha-sbuild
    [sid-alpha-sbuild]
    description=Debian sid chroot for alpha
    type=directory
    directory=/local_scratch/sid-alpha-sbuild
    profile=sbuild
    #aliases=sid
    groups=root,sbuild,glaubitz,buildd
    root-groups=root,sbuild,glaubitz,buildd
    root@z6:~>

    root@z6:~> cat /etc/schroot/sbuild/fstab
    # fstab: static file system information for chroots.
    # Note that the mount point will be prefixed by the chroot path
    # (CHROOT_PATH)
    #
    # <file system> <mount point> <type> <options> <dump> <pass>
    /proc /proc none rw,bind 0 0
    /sys /sys none rw,bind 0 0
    /dev/pts /dev/pts none rw,bind 0 0
    tmpfs /dev/shm tmpfs defaults 0 0
    # Mount a large scratch space for the build, so we don't use up
    # space on an LVM snapshot of the chroot itself.
    /home/glaubitz /home/glaubitz none rw,bind 0 0
    root@z6:~>

    To bisect, just run the normal git bisect process from the and just run the test command in the emulated schroot from a second terminal.

    Adrian

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to John Paul Adrian Glaubitz on Tue Dec 13 18:50:01 2022
    On 12/13/22 17:25, John Paul Adrian Glaubitz wrote:
    On 11/13/22 00:45, John Paul Adrian Glaubitz wrote:
    I just noticed that there is a regression in glibc on alpha with version 2.34 or later.

    Looking at the build logs for Debian's 2.34-8 [1], 2.35-4 [2] and 2.36-4 [3], it's obvious
    there is something wrong given the many "Segmentation Fault" errors.

    This regression was introduced by the following commit:

    Reported here: https://sourceware.org/bugzilla/show_bug.cgi?id=29899

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to All on Wed Dec 14 18:30:01 2022
    SGkgQWRyaWFuLA0KDQpPbiAxMy4xMi4yMiAxNzoyMSwgSm9obiBQYXVsIEFkcmlhbiBHbGF1 Yml0eiB3cm90ZToNCj4gSGkhDQo+IA0KPiBPbiAxMi8xMy8yMiAxMDo1MiwgSm9obiBQYXVs IEFkcmlhbiBHbGF1Yml0eiB3cm90ZToNCj4+IFlvdSBjb3VsZCBjcm9zcy1jb21waWxlIGds aWJjLiBUaGF0J3MgbW9zdCBsaWtlbHkgd2hhdCBJIGFtIGdvaW5nIHRvIGRvLg0KPiANCj4g Rm9yIHRoZSByZWNvcmQsIGhlcmUncyBob3cgSSBhbSBkb2luZyBpdC4NCj4gDQo+IFsuLi5d DQoNClRoYW5rcyBmb3IgdGhhdCwgdGhpcyBpcyBxdWl0ZSB1c2VmdWwuDQoNCj4gNC4gRW50 ZXIgYWxwaGEgc2Nocm9vdCBhbmQgcnVuIHRoZSB0aGUgZm9sbG93aW5nIGNvbW1hbmQgZnJv bSB0aGUgYnVpbGQgDQo+IGRpcmVjdG9yeToNCj4gDQo+ICDCoMKgIChzaWQtYWxwaGEtc2J1 aWxkKWdsYXViaXR6QHo2On4vZ2xpYmMtZ2l0L2J1aWxkJCANCj4gTERfTElCUkFSWV9QQVRI PS9ob21lL2dsYXViaXR6L2dsaWJjLWdpdC9idWlsZCAvYmluL2Jhc2gNCj4gDQo+ICDCoMKg IElmIHRoZSBidWcgaXMgcHJlc2VudCwgdGhpcyBjb21tYW5kIHdpbGwgc2VnZmF1bHQ6DQo+ IA0KPiAgwqDCoCBTZWdtZW50YXRpb24gZmF1bHQNCj4gDQo+ICDCoMKgIE90aGVyd2lzZSBp dCB3aWxsIGp1c3Qgc3Bhd24gYW5vdGhlciBiYXNoIHdoaWNoIGNhbiBiZSBleGl0ZWQgd2l0 aCANCj4gImV4aXQiOg0KPiANCj4gIMKgwqAgKHNpZC1hbHBoYS1zYnVpbGQpZ2xhdWJpdHpA ejY6fi9nbGliYy1naXQvYnVpbGQkIA0KPiBMRF9MSUJSQVJZX1BBVEg9L2hvbWUvZ2xhdWJp dHovZ2xpYmMtZ2l0L2J1aWxkIC9iaW4vYmFzaA0KPiAgwqDCoCAoc2lkLWFscGhhLXNidWls ZClnbGF1Yml0ekB6Njp+L2dsaWJjLWdpdC9idWlsZCQNCj4gIMKgwqAgZXhpdA0KPiAgwqDC oCAoc2lkLWFscGhhLXNidWlsZClnbGF1Yml0ekB6Njp+L2dsaWJjLWdpdC9idWlsZCQNCg0K Q2FuIHdlIGJlIHN1cmUgdGhhdCB0aGlzIHJlcHJvZHVjZXIgaWRlbnRpZmllcyB0aGUgc2Ft ZSBwcm9ibGVtIHRoYW4gdGhlIA0KYnVpbGQgZmFpbHVyZXMgZnJvbSB0aGUgb3JpZ2luYWwg cG9zdCAoWzFdKT8NCg0KWzFdOiBodHRwczovL2xpc3RzLmRlYmlhbi5vcmcvZGViaWFuLWFs cGhhLzIwMjIvMTEvbXNnMDAwMDMuaHRtbA0KDQpSZWdhcmRsZXNzLCBJIGNhbiBjb25maXJt IHRoaXMgb24gbXkgRFMxNToNCg0KYGBgDQpyb290QGRzMTU6L3Nydi9zdG9yYWdlL2J1aWxk IyANCkxEX0xJQlJBUllfUEFUSD0kUFdEL2dsaWJjLWF0LTM2MjMxYmVlN2FiMzZkNTlkZDEy MWVhODViOTE0MTFhZTg2OTQ1ZjMgDQovYmluL2Jhc2gNCnJvb3RAZHMxNTovc3J2L3N0b3Jh Z2UvYnVpbGQjIGVjaG8gJD8NCjANCnJvb3RAZHMxNTovc3J2L3N0b3JhZ2UvYnVpbGQjIGV4 aXQNCmV4aXQNCg0Kcm9vdEBkczE1Oi9zcnYvc3RvcmFnZS9idWlsZCMgDQpMRF9MSUJSQVJZ X1BBVEg9JFBXRC9nbGliYy1hdC02YzU3ZDMyMDQ4NDk4OGU4N2U0NDZlMmU2MGNlNDI4MTZi ZjUxZDUzIA0KL2Jpbi9iYXNoDQpTZWdtZW50YXRpb24gZmF1bHQNCnJvb3RAZHMxNTovc3J2 L3N0b3JhZ2UvYnVpbGQjIGVjaG8gJD8NCjEzOQ0KYGBgDQoNCi4uLjZjNTdkMzIwNDg0OTg4 ZTg3ZTQ0NmUyZTYwY2U0MjgxNmJmNTFkNTMgaXMgdGhlIGZpcnN0IGJhZCBjb21taXQgYW5k IA0KMzYyMzFiZWU3YWIzNmQ1OWRkMTIxZWE4NWI5MTQxMWFlODY5NDVmMyBpcyBpdHMgcGFy ZW50Lg0KDQpEbyB3ZSBhbHNvIGhhdmUgYSByZXN1bHQgZm9yIA0KZ2xpYmNANmM1N2QzMjA0 ODQ5ODhlODdlNDQ2ZTJlNjBjZTQyODE2YmY1MWQ1MyB3aXRoIGAtbWNwdT1ldjY3YD8NCg0K Q2hlZXJzLA0KRnJhbmsNCg0K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to Frank Scheiner on Wed Dec 14 20:50:01 2022
    On 14.12.22 18:21, Frank Scheiner wrote:
    [...]
    Regardless, I can confirm this on my DS15:

    ```
    root@ds15:/srv/storage/build# LD_LIBRARY_PATH=$PWD/glibc-at-36231bee7ab36d59dd121ea85b91411ae86945f3 /bin/bash
    root@ds15:/srv/storage/build# echo $?
    0
    root@ds15:/srv/storage/build# exit
    exit

    root@ds15:/srv/storage/build# LD_LIBRARY_PATH=$PWD/glibc-at-6c57d320484988e87e446e2e60ce42816bf51d53 /bin/bash
    Segmentation fault
    root@ds15:/srv/storage/build# echo $?
    139
    ```

    ...6c57d320484988e87e446e2e60ce42816bf51d53 is the first bad commit and 36231bee7ab36d59dd121ea85b91411ae86945f3 is its parent.

    Do we also have a result for
    glibc@6c57d320484988e87e446e2e60ce42816bf51d53 with `-mcpu=ev67`?

    ``` root@ds15:/srv/storage/build/glibc-at-6c57d320484988e87e446e2e60ce42816bf51d53-ev67#
    CC="alpha-linux-gnu-gcc-12 -mcpu=ev67 -mtune=ev67 "
    CXX="alpha-linux-gnu-g++-12 -mcpu=ev67 -mtune=ev67 "
    MIG="alpha-linux-gnu-mig" ../../glibc/configure
    --host=alphaev67-linux-gnu --disable-werror --prefix=/usr --disable-sanity-checks

    [...]

    root@ds15:/srv/storage/build# LD_LIBRARY_PATH=$PWD/glibc-at-6c57d320484988e87e446e2e60ce42816bf51d53-ev67 /bin/bash
    Segmentation fault
    ```

    Unfortunately it also doesn't work here when optimized for EV67.

    Cheers,
    Frank

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Frank Scheiner on Wed Dec 14 21:00:01 2022
    Hi!

    On 12/14/22 20:46, Frank Scheiner wrote:
    ``` root@ds15:/srv/storage/build/glibc-at-6c57d320484988e87e446e2e60ce42816bf51d53-ev67#
    CC="alpha-linux-gnu-gcc-12 -mcpu=ev67 -mtune=ev67 " CXX="alpha-linux-gnu-g++-12 -mcpu=ev67 -mtune=ev67 " MIG="alpha-linux-gnu-mig" ../../glibc/configure
    --host=alphaev67-linux-gnu --disable-werror --prefix=/usr --disable-sanity-checks

    [...]

    root@ds15:/srv/storage/build# LD_LIBRARY_PATH=$PWD/glibc-at-6c57d320484988e87e446e2e60ce42816bf51d53-ev67 /bin/bash
    Segmentation fault
    ```

    Unfortunately it also doesn't work here when optimized for EV67.

    OK, this just confirms what my cross-compile tests with "-mcpu=ev67 -mtune=ev67"
    where the segfault wasn't fixed either by raising the baseline.

    If you have a user account for glibc bugzilla, you should subscribe to the bug report I opened for this particular issue [1]. H. J. Lu raises a good question, namely whether alpha has any hardcoded values for "struct rtld_global_ro {}".

    Adrian

    [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29899

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to John Paul Adrian Glaubitz on Wed Dec 14 21:20:01 2022
    On 14.12.22 20:55, John Paul Adrian Glaubitz wrote:
    [...]
    Unfortunately it also doesn't work here when optimized for EV67.

    OK, this just confirms what my cross-compile tests with "-mcpu=ev67 -mtune=ev67"
    where the segfault wasn't fixed either by raising the baseline.

    If you have a user account for glibc bugzilla, you should subscribe to
    the bug
    report I opened for this particular issue [1].

    Or can you just put me on the CC list?

    H. J. Lu raises a good
    question,
    namely whether alpha has any hardcoded values for "struct rtld_global_ro
    {}".

    I have no answer for that.

    Cheers,
    Frank

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to John Paul Adrian Glaubitz on Wed Dec 14 21:30:01 2022
    Hi Adrian,

    On 14.12.22 20:51, John Paul Adrian Glaubitz wrote:
    [...]
    Can we be sure that this reproducer identifies the same problem than
    the build failures from the original post ([1])?

    [1]: https://lists.debian.org/debian-alpha/2022/11/msg00003.html

    Well, this is how I identified that there was a problem with glibc on
    alpha.

    I built the packages manually with the testsuite enabled and installed them into a chroot for testing which resulted in a segfault when dpkg tried to configure the libc-bin package.

    I assume the many testsuite failures are a direct result of this bug which just causes many tests to segfault. We had a similar problem on sparc64
    where
    a single bug in the static build caused many testsuite failures.

    I see.

    Interestingly, when I checkout the tag glibc-2.34 and disabled the _dl_minsigstacksize symbol
    in "struct rtld_global_ro {}" again with the following hack, I'm no
    longer getting a segfault
    but a floating point exception:

    [...]

    Could you verify this on your DS-15?

    I'll do that tomorrow. The thing is that this diff doesn't apply cleanly:

    ```
    root@ds15:/srv/storage/glibc# git checkout glibc-2.34
    Note: switching to 'glibc-2.34'.

    You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this
    state without impacting any branches by switching back to a branch.

    [...]
    HEAD is now at ae37d06c7d Update ChangeLog.old/ChangeLog.23.

    root@ds15:/srv/storage/glibc# patch -p1 < ../../glibc-fix.patch
    patching file elf/dl-sysdep.c
    Hunk #1 FAILED at 116.
    Hunk #2 FAILED at 185.
    2 out of 2 hunks FAILED -- saving rejects to file elf/dl-sysdep.c.rej
    patching file elf/rtld_static_init.c
    patching file sysdeps/generic/ldsodefs.h
    patching file sysdeps/unix/sysv/linux/sysconf-pthread_stack_min.h
    Hunk #1 succeeded at 22 with fuzz 1.
    patching file sysdeps/unix/sysv/linux/sysconf.c
    Hunk #1 succeeded at 84 with fuzz 2.
    ```

    Not sure why, shouldn't we have the same source state? Should I try to
    apply the rejected stuff manually?

    Cheers,
    Frank

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to John Paul Adrian Glaubitz on Wed Dec 14 21:50:02 2022
    On 14.12.22 21:32, John Paul Adrian Glaubitz wrote:
    Hi!

    On 12/14/22 21:16, Frank Scheiner wrote:
    I'll do that tomorrow. The thing is that this diff doesn't apply cleanly:

    Which version of the workaround diff did you use? There are two.

    There is one that applies cleanly on top of 6c57d320484988e87e446e2e60ce42816bf51d53
    and a second one that applies cleanly on top of glibc-2.34, I posted
    both. There were
    some changes between 6c57d320484988e87e446e2e60ce42816bf51d53 and
    glibc-2.34 in the
    minstksize/stksize code which is why you need the second diff that was
    also part of
    my mail.

    I used the one from the bottom of your mail, just below "Interestingly,
    when I checkout the tag glibc-2.34 and disabled the _dl_minsigstacksize
    symbol in "struct rtld_global_ro {}" again with the following hack, I'm
    no longer getting a segfault but a floating point exception: "

    I'm attaching the second diff as a patch.

    I think there's some whitespace difference. I manually applied the
    rejected stuff, made a `git diff` and comparing that to your attached
    patch gives:

    ```
    root@nfs:/srv/nfs/ds15/root/srv# diff -Nur glibc-fix-2.patch bz20305-workaround2.patch
    --- glibc-fix-2.patch 2022-12-14 21:24:01.259696291 +0100
    +++ bz20305-workaround2.patch 2022-12-14 21:37:25.439904377 +0100
    @@ -1,5 +1,5 @@
    diff --git a/elf/dl-sysdep.c b/elf/dl-sysdep.c
    -index d47bef1340..d3dc6e5c57 100644
    +index d47bef1340..8462e5859a 100644
    --- a/elf/dl-sysdep.c
    +++ b/elf/dl-sysdep.c
    @@ -116,10 +116,10 @@ _dl_sysdep_start (void **start_argptr,
    @@ -12,7 +12,7 @@
    - GLRO(dl_minsigstacksize) = CONSTANT_MINSIGSTKSZ;
    + /* /\* NB: Default to a constant CONSTANT_MINSIGSTKSZ. *\/ */
    + /* _Static_assert (__builtin_constant_p (CONSTANT_MINSIGSTKSZ), */
    -+ /* "CONSTANT_MINSIGSTKSZ is constant"); */
    ++ /* "CONSTANT_MINSIGSTKSZ is constant"); */
    + /* GLRO(dl_minsigstacksize) = CONSTANT_MINSIGSTKSZ; */

    for (av = GLRO(dl_auxv); av->a_type != AT_NULL; set_seen (av++))
    @@ -25,8 +25,8 @@
    - GLRO(dl_minsigstacksize) = av->a_un.a_val;
    - break;
    + /* case AT_MINSIGSTKSZ: */
    -+ /* GLRO(dl_minsigstacksize) = av->a_un.a_val;
  • From John Paul Adrian Glaubitz@21:1/5 to Frank Scheiner on Wed Dec 14 21:40:02 2022
    This is a multi-part message in MIME format.
    Hi!

    On 12/14/22 21:16, Frank Scheiner wrote:
    I'll do that tomorrow. The thing is that this diff doesn't apply cleanly:

    Which version of the workaround diff did you use? There are two.

    There is one that applies cleanly on top of 6c57d320484988e87e446e2e60ce42816bf51d53
    and a second one that applies cleanly on top of glibc-2.34, I posted both. There were
    some changes between 6c57d320484988e87e446e2e60ce42816bf51d53 and glibc-2.34 in the
    minstksize/stksize code which is why you need the second diff that was also part of
    my mail.

    I'm attaching the second diff as a patch.

    Adrian

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

    ZGlmZiAtLWdpdCBhL2VsZi9kbC1zeXNkZXAuYyBiL2VsZi9kbC1zeXNkZXAuYwppbmRleCBk NDdiZWYxMzQwLi44NDYyZTU4NTlhIDEwMDY0NAotLS0gYS9lbGYvZGwtc3lzZGVwLmMKKysr IGIvZWxmL2RsLXN5c2RlcC5jCkBAIC0xMTYsMTAgKzExNiwxMCBAQCBfZGxfc3lzZGVwX3N0 YXJ0ICh2b2lkICoqc3RhcnRfYXJncHRyLAogICB1c2VyX2VudHJ5ID0gKEVsZlcoQWRkcikp IEVOVFJZX1BPSU5UOwogICBHTFJPKGRsX3BsYXRmb3JtKSA9IE5VTEw7IC8qIERlZmF1bHQg dG8gbm90aGluZyBrbm93biBhYm91dCB0aGUgcGxhdGZvcm0uICAqLwogCi0gIC8qIE5COiBE ZWZhdWx0IHRvIGEgY29uc3RhbnQgQ09OU1RBTlRfTUlOU0lHU1RLU1ouICAqLwotICBfU3Rh dGljX2Fzc2VydCAoX19idWlsdGluX2NvbnN0YW50X3AgKENPTlNUQU5UX01JTlNJR1NUS1Na KSwKLQkJICAiQ09OU1RBTlRfTUlOU0lHU1RLU1ogaXMgY29uc3RhbnQiKTsKLSAgR0xSTyhk bF9taW5zaWdzdGFja3NpemUpID0gQ09OU1RBTlRfTUlOU0lHU1RLU1o7CisgIC8qIC9cKiBO QjogRGVmYXVsdCB0byBhIGNvbnN0YW50IENPTlNUQU5UX01JTlNJR1NUS1NaLiAgKlwvICov CisgIC8qIF9TdGF0aWNfYXNzZXJ0IChfX2J1aWx0aW5fY29uc3RhbnRfcCAoQ09OU1RBTlRf TUlOU0lHU1RLU1opLCAqLworICAvKiAJCSAgIkNPTlNUQU5UX01JTlNJR1NUS1NaIGlzIGNv bnN0YW50Iik7ICovCisgIC8qIEdMUk8oZGxfbWluc2lnc3RhY2tzaXplKSA9IENPTlNUQU5U X01JTlNJR1NUS1NaOyAqLwogCiAgIGZvciAoYXYgPSBHTFJPKGRsX2F1eHYpOyBhdi0+YV90 eXBlICE9IEFUX05VTEw7IHNldF9zZWVuIChhdisrKSkKICAgICBzd2l0Y2ggKGF2LT5hX3R5 cGUpCkBAIC0xODUsOSArMTg1LDkgQEAgX2RsX3N5c2RlcF9zdGFydCAodm9pZCAqKnN0YXJ0 X2FyZ3B0ciwKICAgICAgIGNhc2UgQVRfUkFORE9NOgogCV9kbF9yYW5kb20gPSAodm9pZCAq KSBhdi0+YV91bi5hX3ZhbDsKIAlicmVhazsKLSAgICAgIGNhc2UgQVRfTUlOU0lHU1RLU1o6 Ci0JR0xSTyhkbF9taW5zaWdzdGFja3NpemUpID0gYXYtPmFfdW4uYV92YWw7Ci0JYnJlYWs7 CisgICAgICAvKiBjYXNlIEFUX01JTlNJR1NUS1NaOiAqLworICAgICAgLyogCUdMUk8oZGxf bWluc2lnc3RhY2tzaXplKSA9IGF2LT5hX3VuLmFfdmFsOyAqLworICAgICAgLyogCWJyZWFr OyAqLwogICAgICAgRExfUExBVEZPUk1fQVVYVgogICAgICAgfQogCmRpZmYgLS1naXQgYS9l bGYvcnRsZF9zdGF0aWNfaW5pdC5jIGIvZWxmL3J0bGRfc3RhdGljX2luaXQuYwppbmRleCAz ZjhhYmI2ODAwLi5hZWFjNDkyMjM1IDEwMDY0NAotLS0gYS9lbGYvcnRsZF9zdGF0aWNfaW5p dC5jCisrKyBiL2VsZi9ydGxkX3N0YXRpY19pbml0LmMKQEAgLTY3LDkgKzY3LDkgQEAgX19y dGxkX3N0YXRpY19pbml0IChzdHJ1Y3QgbGlua19tYXAgKm1hcCkKICAgZGwtPl9kbF9od2Nh cCA9IF9kbF9od2NhcDsKICAgZXh0ZXJuIF9fdHlwZW9mIChkbC0+X2RsX2h3Y2FwMikgX2Rs X2h3Y2FwMiBhdHRyaWJ1dGVfaGlkZGVuOwogICBkbC0+X2RsX2h3Y2FwMiA9IF9kbF9od2Nh cDI7Ci0gIGV4dGVybiBfX3R5cGVvZiAoZGwtPl9kbF9taW5zaWdzdGFja3NpemUpIF9kbF9t aW5zaWdzdGFja3NpemUKLSAgICBhdHRyaWJ1dGVfaGlkZGVuOwotICBkbC0+X2RsX21pbnNp Z3N0YWNrc2l6ZSA9IF9kbF9taW5zaWdzdGFja3NpemU7CisgIC8qIGV4dGVybiBfX3R5cGVv ZiAoZGwtPl9kbF9taW5zaWdzdGFja3NpemUpIF9kbF9taW5zaWdzdGFja3NpemUgKi8KKyAg LyogICBhdHRyaWJ1dGVfaGlkZGVuOyAqLworICAvKiBkbC0+X2RsX21pbnNpZ3N0YWNrc2l6 ZSA9IF9kbF9taW5zaWdzdGFja3NpemU7ICovCiAgIGV4dGVybiBfX3R5cGVvZiAoZGwtPl9k bF9wYWdlc2l6ZSkgX2RsX3BhZ2VzaXplIGF0dHJpYnV0ZV9oaWRkZW47CiAgIGRsLT5fZGxf cGFnZXNpemUgPSBfZGxfcGFnZXNpemU7CiAgIGV4dGVybiBfX3R5cGVvZiAoZGwtPl9kbF90 bHNfc3RhdGljX2FsaWduKSBfZGxfdGxzX3N0YXRpY19hbGlnbgpkaWZmIC0tZ2l0IGEvc3lz ZGVwcy9nZW5lcmljL2xkc29kZWZzLmggYi9zeXNkZXBzL2dlbmVyaWMvbGRzb2RlZnMuaApp bmRleCA5YzE1MjU5MjM2Li42MjExNzcyN2UxIDEwMDY0NAotLS0gYS9zeXNkZXBzL2dlbmVy aWMvbGRzb2RlZnMuaAorKysgYi9zeXNkZXBzL2dlbmVyaWMvbGRzb2RlZnMuaApAQCAtNTQ1 LDkgKzU0NSw2IEBAIHN0cnVjdCBydGxkX2dsb2JhbF9ybwogICAvKiBDYWNoZWQgdmFsdWUg b2YgYGdldHBhZ2VzaXplICgpJy4gICovCiAgIEVYVEVSTiBzaXplX3QgX2RsX3BhZ2VzaXpl OwogCi0gIC8qIENhY2hlZCB2YWx1ZSBvZiBgc3lzY29uZiAoX1NDX01JTlNJR1NUS1NaKScu ICAqLwotICBFWFRFUk4gc2l6ZV90IF9kbF9taW5zaWdzdGFja3NpemU7Ci0KICAgLyogRG8g d2UgcmVhZCBmcm9tIGxkLnNvLmNhY2hlPyAgKi8KICAgRVhURVJOIGludCBfZGxfaW5oaWJp dF9jYWNoZTsKIApkaWZmIC0tZ2l0IGEvc3lzZGVwcy91bml4L3N5c3YvbGludXgvc3lzY29u Zi1wdGhyZWFkX3N0YWNrX21pbi5oIGIvc3lzZGVwcy91bml4L3N5c3YvbGludXgvc3lzY29u Zi1wdGhyZWFkX3N0YWNrX21pbi5oCmluZGV4IDllMGViMGY3ZmMuLjJiYTEzMmUxZmUgMTAw NjQ0Ci0tLSBhL3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4L3N5c2NvbmYtcHRocmVhZF9zdGFj a19taW4uaAorKysgYi9zeXNkZXBzL3VuaXgvc3lzdi9saW51eC9zeXNjb25mLXB0aHJlYWRf c3RhY2tfbWluLmgKQEAgLTIyLDcgKzIyLDcgQEAgc3RhdGljIGlubGluZSBsb25nIGludAog X19nZXRfcHRocmVhZF9zdGFja19taW4gKHZvaWQpCiB7CiAgIC8qIHN5c2NvbmYgKF9TQ19U SFJFQURfU1RBQ0tfTUlOKSA+PSBzeXNjb25mIChfU0NfTUlOU0lHU1RLU1opLiAgKi8KLSAg bG9uZyBpbnQgcHRocmVhZF9zdGFja19taW4gPSBHTFJPKGRsX21pbnNpZ3N0YWNrc2l6ZSk7 CisgIGxvbmcgaW50IHB0aHJlYWRfc3RhY2tfbWluID0gNDA5NjsKICAgYXNzZXJ0IChwdGhy ZWFkX3N0YWNrX21pbiAhPSAwKTsKICAgX1N0YXRpY19hc3NlcnQgKF9fYnVpbHRpbl9jb25z dGFudF9wIChQVEhSRUFEX1NUQUNLX01JTiksCiAJCSAgIlBUSFJFQURfU1RBQ0tfTUlOIGlz IGNvbnN0YW50Iik7CmRpZmYgLS1naXQgYS9zeXNkZXBzL3VuaXgvc3lzdi9saW51eC9zeXNj b25mLmMgYi9zeXNkZXBzL3VuaXgvc3lzdi9saW51eC9zeXNjb25mLmMKaW5kZXggZGFhZWVi N2QzNi4uMjRhZmIyZmRjNSAxMDA2NDQKLS0tIGEvc3lzZGVwcy91bml4L3N5c3YvbGludXgv c3lzY29uZi5jCisrKyBiL3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4L3N5c2NvbmYuYwpAQCAt ODQsMTEgKzg0LDExIEBAIF9fc3lzY29uZiAoaW50IG5hbWUpCiAgICAgICBicmVhazsKIAog ICAgIGNhc2UgX1NDX01JTlNJR1NUS1NaOgotICAgICAgYXNzZXJ0IChHTFJPKGRsX21pbnNp Z3N0YWNrc2l6ZSkgIT0gMCk7Ci0gICAgICByZXR1cm4gR0xSTyhkbF9taW5zaWdzdGFja3Np emUpOworICAgICAgLy8gICAgICBhc3NlcnQgKEdMUk8oZGxfbWluc2lnc3RhY2tzaXplKSAh PSAwKTsKKyAgICAgIHJldHVybiA0MDk2OyAvLyBHTFJPKGRsX21pbnNpZ3N0YWNrc2l6ZSk7 CiAKICAgICBjYXNlIF9TQ19TSUdTVEtTWjoKLSAgICAgIHJldHVybiBzeXNjb25mX3NpZ3N0 a3N6ICgpOworICAgICAgcmV0dXJuIDE2Mzg0IDsgLy9zeXNjb25mX3NpZ3N0a3N6ICgpOwog CiAgICAgZGVmYXVsdDoKICAgICAgIGJyZWFrOwo=

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Frank Scheiner on Thu Dec 15 09:20:01 2022
    Hi!

    On 12/14/22 21:44, Frank Scheiner wrote:
    I'm attaching the second diff as a patch.

    I think there's some whitespace difference. I manually applied the
    rejected stuff, made a `git diff` and comparing that to your attached
    patch gives:

    Or just use the attached patch file from my previous mail.

    If your glibc fails with Floating Point exception, I fear there might be
    a second bug hiding somewhere which we need to bisect as well. This is particularly annoying since we would have to apply the above diff for
    every bisecting step.

    But we'll see.

    Adrian

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to All on Thu Dec 15 11:00:01 2022
    SGksDQoNCk9uIDE1LjEyLjIyIDA5OjA5LCBKb2huIFBhdWwgQWRyaWFuIEdsYXViaXR6IHdy b3RlOg0KPiBIaSENCj4gDQo+IE9uIDEyLzE0LzIyIDIxOjQ0LCBGcmFuayBTY2hlaW5lciB3 cm90ZToNCj4+PiBJJ20gYXR0YWNoaW5nIHRoZSBzZWNvbmQgZGlmZiBhcyBhIHBhdGNoLg0K Pj4NCj4+IEkgdGhpbmsgdGhlcmUncyBzb21lIHdoaXRlc3BhY2UgZGlmZmVyZW5jZS4gSSBt YW51YWxseSBhcHBsaWVkIHRoZQ0KPj4gcmVqZWN0ZWQgc3R1ZmYsIG1hZGUgYSBgZ2l0IGRp ZmZgIGFuZCBjb21wYXJpbmcgdGhhdCB0byB5b3VyIGF0dGFjaGVkDQo+PiBwYXRjaCBnaXZl czoNCj4gDQo+IE9yIGp1c3QgdXNlIHRoZSBhdHRhY2hlZCBwYXRjaCBmaWxlIGZyb20gbXkg cHJldmlvdXMgbWFpbC4NCg0KWWVhaCwgZGlkIHRoYXQgaW4gdGhlIGVuZCB0byBiZSBzdXJl LCBidXQgaXQgbG9va3MgbGlrZSBib3RoIGFyZSANCmluY29tcGxldGUgKGJlY2F1c2UgYm90 aCB2ZXJzaW9ucyBnYXZlIHRoZSBmb2xsb3dpbmcgcmVzdWx0KToNCg0KYGBgDQpyb290QGRz MTU6L3Nydi9zdG9yYWdlL2dsaWJjIyBnaXQgc3RhdHVzDQpIRUFEIGRldGFjaGVkIGF0IGds aWJjLTIuMzQNCm5vdGhpbmcgdG8gY29tbWl0LCB3b3JraW5nIHRyZWUgY2xlYW4NCg0Kcm9v dEBkczE1Oi9zcnYvc3RvcmFnZS9nbGliYyMgcGF0Y2ggLXAxIDwgLi4vLi4vYnoyMDMwNS13 b3JrYXJvdW5kMi5wYXRjaA0KcGF0Y2hpbmcgZmlsZSBlbGYvZGwtc3lzZGVwLmMNCnBhdGNo aW5nIGZpbGUgZWxmL3J0bGRfc3RhdGljX2luaXQuYw0KcGF0Y2hpbmcgZmlsZSBzeXNkZXBz L2dlbmVyaWMvbGRzb2RlZnMuaA0KcGF0Y2hpbmcgZmlsZSBzeXNkZXBzL3VuaXgvc3lzdi9s aW51eC9zeXNjb25mLXB0aHJlYWRfc3RhY2tfbWluLmgNCnBhdGNoaW5nIGZpbGUgc3lzZGVw cy91bml4L3N5c3YvbGludXgvc3lzY29uZi5jDQoNCnJvb3RAZHMxNTovc3J2L3N0b3JhZ2Uv Z2xpYmMjIGNkIC4uL2J1aWxkL2dsaWJjLTIuMzQtcGx1cy1wYXRjaC8NCnJvb3RAZHMxNTov c3J2L3N0b3JhZ2UvYnVpbGQvZ2xpYmMtMi4zNC1wbHVzLXBhdGNoIyANCkNDPSJhbHBoYS1s aW51eC1nbnUtZ2NjLTEyIC1tY3B1PWV2NjcgLW10dW5lPWV2NjcgIiANCkNYWD0iYWxwaGEt bGludXgtZ251LWcrKy0xMiAtbWNwdT1ldjY3IC1tdHVuZT1ldjY3ICIgDQpNSUc9ImFscGhh LWxpbnV4LWdudS1taWciIC4uLy4uL2dsaWJjL2NvbmZpZ3VyZSANCi0taG9zdD1hbHBoYWV2 NjctbGludXgtZ251IC0tZGlzYWJsZS13ZXJyb3IgLS1wcmVmaXg9L3VzciANCi0tZGlzYWJs ZS1zYW5pdHktY2hlY2tzDQpbLi4uXQ0KDQpyb290QGRzMTU6L3Nydi9zdG9yYWdlL2J1aWxk L2dsaWJjLTIuMzQtcGx1cy1wYXRjaCMgdGltZSBtYWtlDQpbLi4uXQ0KYWxwaGEtbGludXgt Z251LWdjYy0xMiAtbWNwdT1ldjY3IC1tdHVuZT1ldjY3IA0KLi4vc3lzZGVwcy91bml4L3N5 c3YvbGludXgvYWxwaGEvc3lzY29uZi5jIC1jIC1zdGQ9Z251MTEgLWZnbnU4OS1pbmxpbmUg DQotZyAtTzIgLVdhbGwgLVd3cml0ZS1zdHJpbmdzIC1XdW5kZWYgLWZtZXJnZS1hbGwtY29u c3RhbnRzIA0KLWZyb3VuZGluZy1tYXRoIC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tY29t bW9uIC1Xc3RyaWN0LXByb3RvdHlwZXMgDQotV29sZC1zdHlsZS1kZWZpbml0aW9uIC1mbWF0 aC1lcnJubyAtbWxvbmctZG91YmxlLTEyOCAtbWllZWUgDQotbWZwLXJvdW5kaW5nLW1vZGU9 ZCAgIC1mZXhjZXB0aW9ucyANCi1ER0VUQ09ORl9ESVI9JyIvdXNyL2xpYmV4ZWMvZ2V0Y29u ZiInICAtZnRscy1tb2RlbD1pbml0aWFsLWV4ZWMgDQotSS4uL2luY2x1ZGUgLUkvc3J2L3N0 b3JhZ2UvYnVpbGQvZ2xpYmMtMi4zNC1wbHVzLXBhdGNoL3Bvc2l4IA0KLUkvc3J2L3N0b3Jh Z2UvYnVpbGQvZ2xpYmMtMi4zNC1wbHVzLXBhdGNoIA0KLUkuLi9zeXNkZXBzL3VuaXgvc3lz di9saW51eC9hbHBoYS9hbHBoYWV2NjcvZnB1IA0KLUkuLi9zeXNkZXBzL2FscGhhL2FscGhh ZXY2Ny9mcHUgDQotSS4uL3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4L2FscGhhL2FscGhhZXY2 NyANCi1JLi4vc3lzZGVwcy91bml4L3N5c3YvbGludXgvYWxwaGEvZnB1ICAtSS4uL3N5c2Rl cHMvYWxwaGEvZnB1IA0KLUkuLi9zeXNkZXBzL3VuaXgvc3lzdi9saW51eC9hbHBoYSAgLUku Li9zeXNkZXBzL2FscGhhL25wdGwgDQotSS4uL3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4L3dv cmRzaXplLTY0IA0KLUkuLi9zeXNkZXBzL2llZWU3NTQvbGRibC02NC0xMjggIC1JLi4vc3lz ZGVwcy9pZWVlNzU0L2xkYmwtb3B0IA0KLUkuLi9zeXNkZXBzL3VuaXgvc3lzdi9saW51eC9p bmNsdWRlIC1JLi4vc3lzZGVwcy91bml4L3N5c3YvbGludXggDQotSS4uL3N5c2RlcHMvbnB0 bCAgLUkuLi9zeXNkZXBzL3B0aHJlYWQgIC1JLi4vc3lzZGVwcy9nbnUgDQotSS4uL3N5c2Rl cHMvdW5peC9pbmV0ICAtSS4uL3N5c2RlcHMvdW5peC9zeXN2ICAtSS4uL3N5c2RlcHMvdW5p eC9hbHBoYSANCi1JLi4vc3lzZGVwcy91bml4ICAtSS4uL3N5c2RlcHMvcG9zaXggIC1JLi4v c3lzZGVwcy9hbHBoYS9hbHBoYWV2NjcgDQotSS4uL3N5c2RlcHMvYWxwaGEvYWxwaGFldjYg IC1JLi4vc3lzZGVwcy9hbHBoYS9hbHBoYWV2NSANCi1JLi4vc3lzZGVwcy9hbHBoYSAgLUku Li9zeXNkZXBzL3dvcmRzaXplLTY0IA0KLUkuLi9zeXNkZXBzL2llZWU3NTQvbGRibC0xMjgg IC1JLi4vc3lzZGVwcy9pZWVlNzU0L2RibC02NCANCi1JLi4vc3lzZGVwcy9pZWVlNzU0L2Zs dC0zMiAgLUkuLi9zeXNkZXBzL2llZWU3NTQgIC1JLi4vc3lzZGVwcy9nZW5lcmljIA0KLUku LiAtSS4uL2xpYmlvIC1JLiAgLURfTElCQ19SRUVOVFJBTlQgLWluY2x1ZGUgDQovc3J2L3N0 b3JhZ2UvYnVpbGQvZ2xpYmMtMi4zNC1wbHVzLXBhdGNoL2xpYmMtbW9kdWxlcy5oIA0KLURN T0RVTEVfTkFNRT1saWJjIC1pbmNsdWRlIC4uL2luY2x1ZGUvbGliYy1zeW1ib2xzLmggDQot RFRPUF9OQU1FU1BBQ0U9Z2xpYmMgLW8gDQovc3J2L3N0b3JhZ2UvYnVpbGQvZ2xpYmMtMi4z NC1wbHVzLXBhdGNoL3Bvc2l4L3N5c2NvbmYubyAtTUQgLU1QIC1NRiANCi9zcnYvc3RvcmFn ZS9idWlsZC9nbGliYy0yLjM0LXBsdXMtcGF0Y2gvcG9zaXgvc3lzY29uZi5vLmR0IC1NVCAN Ci9zcnYvc3RvcmFnZS9idWlsZC9nbGliYy0yLjM0LXBsdXMtcGF0Y2gvcG9zaXgvc3lzY29u Zi5vDQpJbiBmaWxlIGluY2x1ZGVkIGZyb20gLi4vc3lzZGVwcy9hbHBoYS9sZHNvZGVmcy5o OjQwLA0KICAgICAgICAgICAgICAgICAgZnJvbSAuLi9zeXNkZXBzL2dudS9sZHNvZGVmcy5o OjQ2LA0KICAgICAgICAgICAgICAgICAgZnJvbSAuLi9zeXNkZXBzL3VuaXgvc3lzdi9saW51 eC9sZHNvZGVmcy5oOjI1LA0KICAgICAgICAgICAgICAgICAgZnJvbSAuLi9zeXNkZXBzL3Vu aXgvc3lzdi9saW51eC9zeXNjb25mLmM6MjksDQogICAgICAgICAgICAgICAgICBmcm9tIC4u L3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4L2FscGhhL3N5c2NvbmYuYzoxMjc6DQouLi9zeXNk ZXBzL3VuaXgvc3lzdi9saW51eC9zeXNjb25mLXNpZ3N0a3N6Lmg6IEluIGZ1bmN0aW9uIA0K 4oCYc3lzY29uZl9zaWdzdGtzeuKAmToNCi4uL3N5c2RlcHMvZ2VuZXJpYy9sZHNvZGVmcy5o OjUxMjoyMTogZXJyb3I6IOKAmF9kbF9taW5zaWdzdGFja3NpemXigJkgDQp1bmRlY2xhcmVk IChmaXJzdCB1c2UgaW4gdGhpcyBmdW5jdGlvbik7IGRpZCB5b3UgbWVhbiDigJhtaW5zaWdz dGFja3NpemXigJk/DQogICA1MTIgfCAjIGRlZmluZSBHTFJPKG5hbWUpIF8jI25hbWUNCiAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgXg0KLi4vc3lzZGVwcy91bml4L3N5c3YvbGlu dXgvc3lzY29uZi1zaWdzdGtzei5oOjI0OjMwOiBub3RlOiBpbiBleHBhbnNpb24gDQpvZiBt YWNybyDigJhHTFJP4oCZDQogICAgMjQgfCAgIGxvbmcgaW50IG1pbnNpZ3N0YWNrc2l6ZSA9 IEdMUk8oZGxfbWluc2lnc3RhY2tzaXplKTsNCiAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgXn5+fg0KLi4vc3lzZGVwcy9nZW5lcmljL2xkc29kZWZzLmg6NTEyOjIx OiBub3RlOiBlYWNoIHVuZGVjbGFyZWQgaWRlbnRpZmllciANCmlzIHJlcG9ydGVkIG9ubHkg b25jZSBmb3IgZWFjaCBmdW5jdGlvbiBpdCBhcHBlYXJzIGluDQogICA1MTIgfCAjIGRlZmlu ZSBHTFJPKG5hbWUpIF8jI25hbWUNCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgXg0K Li4vc3lzZGVwcy91bml4L3N5c3YvbGludXgvc3lzY29uZi1zaWdzdGtzei5oOjI0OjMwOiBu b3RlOiBpbiBleHBhbnNpb24gDQpvZiBtYWNybyDigJhHTFJP4oCZDQogICAgMjQgfCAgIGxv bmcgaW50IG1pbnNpZ3N0YWNrc2l6ZSA9IEdMUk8oZGxfbWluc2lnc3RhY2tzaXplKTsNCiAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXn5+fg0KSW4gZmlsZSBpbmNs dWRlZCBmcm9tIC4uL3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4L3N5c2NvbmYuYzozMDoNCi4u L3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4L3N5c2NvbmYtc2lnc3Rrc3ouaDogQXQgdG9wIGxl dmVsOg0KLi4vc3lzZGVwcy91bml4L3N5c3YvbGludXgvc3lzY29uZi1zaWdzdGtzei5oOjIy OjE6IHdhcm5pbmc6IA0K4oCYc3lzY29uZl9zaWdzdGtzeuKAmSBkZWZpbmVkIGJ1dCBub3Qg dXNlZCBbLVd1bnVzZWQtZnVuY3Rpb25dDQogICAgMjIgfCBzeXNjb25mX3NpZ3N0a3N6ICh2 b2lkKQ0KICAgICAgIHwgXn5+fn5+fn5+fn5+fn5+fg0KbWFrZVsyXTogKioqIFsvc3J2L3N0 b3JhZ2UvYnVpbGQvZ2xpYmMtMi4zNC1wbHVzLXBhdGNoL3N5c2QtcnVsZXM6MTc5OiANCi9z cnYvc3RvcmFnZS9idWlsZC9nbGliYy0yLjM0LXBsdXMtcGF0Y2gvcG9zaXgvc3lzY29uZi5v XSBFcnJvciAxDQptYWtlWzJdOiBMZWF2aW5nIGRpcmVjdG9yeSAnL3Nydi9zdG9yYWdlL2ds aWJjL3Bvc2l4Jw0KbWFrZVsxXTogKioqIFtNYWtlZmlsZTo0Nzg6IHBvc2l4L3N1YmRpcl9s aWJdIEVycm9yIDINCm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5ICcvc3J2L3N0b3JhZ2Uv Z2xpYmMnDQptYWtlOiAqKiogW01ha2VmaWxlOjk6IGFsbF0gRXJyb3IgMg0KDQpyZWFsCTMy bTIzLjA4NHMNCnVzZXIJMjNtNy44NjFzDQpzeXMJNW0xMy45NjBzDQpgYGANCg0KTWF5YmUg YWRkaW5nIFsxXSBtaWdodCBoZWxwLCBidXQgdGhlIHBhdGNoIGFjdHVhbGx5IHJlbW92ZXMg aXQuDQoNClsxXTogDQpodHRwczovL2dpdGh1Yi5jb20vYm1pbm9yL2dsaWJjL2NvbW1pdC82 YzU3ZDMyMDQ4NDk4OGU4N2U0NDZlMmU2MGNlNDI4MTZiZjUxZDUzI2RpZmYtYTBmNmNhMzll MDUwMzE3YWRjZjE1NjA2MmFiMDczYmViNTAwYzNjOWQ3NWI0ZDlhZGFkN2E4YTA4ZjQyZTVm Mw0KDQpDaGVlcnMsDQpGcmFuaw0K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to All on Thu Dec 15 11:10:01 2022
    SGksDQoNCk9uIDE1LjEyLjIyIDExOjAyLCBKb2huIFBhdWwgQWRyaWFuIEdsYXViaXR6IHdy b3RlOg0KPiBIaSENCj4gDQo+IE9uIDEyLzE1LzIyIDEwOjQ5LCBGcmFuayBTY2hlaW5lciB3 cm90ZToNCj4+IE1heWJlIGFkZGluZyBbMV0gbWlnaHQgaGVscCwgYnV0IHRoZSBwYXRjaCBh Y3R1YWxseSByZW1vdmVzIGl0Lg0KPiANCj4gSXQncyBtaXNzaW5nIHRoaXMgaHVuazoNCj4g DQo+IGRpZmYgLS1naXQgYS9zeXNkZXBzL3VuaXgvc3lzdi9saW51eC9zeXNjb25mLXNpZ3N0 a3N6LmggDQo+IGIvc3lzZGVwcy91bml4L3N5c3YvbGludXgvc3lzY29uZi1zaWdzdGtzei5o DQo+IGluZGV4IDY0ZDQ1MGIyMmMuLjQ1NTJlNzdkNTkgMTAwNjQ0DQo+IC0tLSBhL3N5c2Rl cHMvdW5peC9zeXN2L2xpbnV4L3N5c2NvbmYtc2lnc3Rrc3ouaA0KPiArKysgYi9zeXNkZXBz L3VuaXgvc3lzdi9saW51eC9zeXNjb25mLXNpZ3N0a3N6LmgNCj4gQEAgLTIxLDcgKzIxLDcg QEANCj4gIMKgc3RhdGljIGxvbmcgaW50DQo+ICDCoHN5c2NvbmZfc2lnc3Rrc3ogKHZvaWQp DQo+ICDCoHsNCj4gLcKgIGxvbmcgaW50IG1pbnNpZ3N0YWNrc2l6ZSA9IEdMUk8oZGxfbWlu c2lnc3RhY2tzaXplKTsNCj4gK8KgIGxvbmcgaW50IG1pbnNpZ3N0YWNrc2l6ZSA9IDQwOTYg OyAvL0dMUk8oZGxfbWluc2lnc3RhY2tzaXplKTsNCj4gIMKgwqAgYXNzZXJ0IChtaW5zaWdz dGFja3NpemUgIT0gMCk7DQo+ICDCoMKgIF9TdGF0aWNfYXNzZXJ0IChfX2J1aWx0aW5fY29u c3RhbnRfcCAoTUlOU0lHU1RLU1opLA0KPiAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCAiTUlOU0lHU1RLU1ogaXMgY29uc3RhbnQiKTsNCj4gDQo+IEkgd2FzIGV4cGVy aW1lbnRpbmcgd2l0aCBhIGN1c3RvbSBzeXNjb25mLXNpZ3N0a3N6LmggbGlrZSBvbiBpYTY0 IHdoaWNoIA0KPiBJIGZvcmdvdCB0byBwdXJnZSwgc29ycnkuDQoNCk9rLCBJIHdpbGwgdXNl IHRoaXMgYW5kIHJ1biBpdCBhZ2Fpbi4NCg0KQ2hlZXJzLA0KRnJhbmsNCg==

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Frank Scheiner on Thu Dec 15 11:10:01 2022
    Hi!

    On 12/15/22 10:49, Frank Scheiner wrote:
    Maybe adding [1] might help, but the patch actually removes it.

    It's missing this hunk:

    diff --git a/sysdeps/unix/sysv/linux/sysconf-sigstksz.h b/sysdeps/unix/sysv/linux/sysconf-sigstksz.h
    index 64d450b22c..4552e77d59 100644
    --- a/sysdeps/unix/sysv/linux/sysconf-sigstksz.h
    +++ b/sysdeps/unix/sysv/linux/sysconf-sigstksz.h
    @@ -21,7 +21,7 @@
    static long int
    sysconf_sigstksz (void)
    {
    - long int minsigstacksize = GLRO(dl_minsigstacksize);
    + long int minsigstacksize = 4096 ; //GLRO(dl_minsigstacksize);
    assert (minsigstacksize != 0);
    _Static_assert (__builtin_constant_p (MINSIGSTKSZ),
    "MINSIGSTKSZ is constant");

    I was experimenting with a custom sysconf-sigstksz.h like on ia64 which I forgot to purge, sorry.

    Adrian

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to All on Thu Dec 15 12:50:01 2022
    SGkgQWRyaWFuLA0KDQpPbiAxNS4xMi4yMiAxMTowNiwgRnJhbmsgU2NoZWluZXIgd3JvdGU6 DQo+IEhpLA0KPiANCj4gT24gMTUuMTIuMjIgMTE6MDIsIEpvaG4gUGF1bCBBZHJpYW4gR2xh dWJpdHogd3JvdGU6DQo+PiBIaSENCj4+DQo+PiBPbiAxMi8xNS8yMiAxMDo0OSwgRnJhbmsg U2NoZWluZXIgd3JvdGU6DQo+Pj4gTWF5YmUgYWRkaW5nIFsxXSBtaWdodCBoZWxwLCBidXQg dGhlIHBhdGNoIGFjdHVhbGx5IHJlbW92ZXMgaXQuDQo+Pg0KPj4gSXQncyBtaXNzaW5nIHRo aXMgaHVuazoNCj4+DQo+PiBkaWZmIC0tZ2l0IGEvc3lzZGVwcy91bml4L3N5c3YvbGludXgv c3lzY29uZi1zaWdzdGtzei5oIA0KPj4gYi9zeXNkZXBzL3VuaXgvc3lzdi9saW51eC9zeXNj b25mLXNpZ3N0a3N6LmgNCj4+IGluZGV4IDY0ZDQ1MGIyMmMuLjQ1NTJlNzdkNTkgMTAwNjQ0 DQo+PiAtLS0gYS9zeXNkZXBzL3VuaXgvc3lzdi9saW51eC9zeXNjb25mLXNpZ3N0a3N6LmgN Cj4+ICsrKyBiL3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4L3N5c2NvbmYtc2lnc3Rrc3ouaA0K Pj4gQEAgLTIxLDcgKzIxLDcgQEANCj4+IMKgwqBzdGF0aWMgbG9uZyBpbnQNCj4+IMKgwqBz eXNjb25mX3NpZ3N0a3N6ICh2b2lkKQ0KPj4gwqDCoHsNCj4+IC3CoCBsb25nIGludCBtaW5z aWdzdGFja3NpemUgPSBHTFJPKGRsX21pbnNpZ3N0YWNrc2l6ZSk7DQo+PiArwqAgbG9uZyBp bnQgbWluc2lnc3RhY2tzaXplID0gNDA5NiA7IC8vR0xSTyhkbF9taW5zaWdzdGFja3NpemUp Ow0KPj4gwqDCoMKgIGFzc2VydCAobWluc2lnc3RhY2tzaXplICE9IDApOw0KPj4gwqDCoMKg IF9TdGF0aWNfYXNzZXJ0IChfX2J1aWx0aW5fY29uc3RhbnRfcCAoTUlOU0lHU1RLU1opLA0K Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICJNSU5TSUdTVEtTWiBp cyBjb25zdGFudCIpOw0KPj4NCj4+IEkgd2FzIGV4cGVyaW1lbnRpbmcgd2l0aCBhIGN1c3Rv bSBzeXNjb25mLXNpZ3N0a3N6LmggbGlrZSBvbiBpYTY0IA0KPj4gd2hpY2ggSSBmb3Jnb3Qg dG8gcHVyZ2UsIHNvcnJ5Lg0KPiANCj4gT2ssIEkgd2lsbCB1c2UgdGhpcyBhbmQgcnVuIGl0 IGFnYWluLg0KDQpJIHJlbmFtZWQgdGhlIGJ1aWxkIGRpcmVjdG9yeSB0byByZWZsZWN0IHRo YXQgdGhlIGJ1aWxkIHdhcyBvcHRpbWl6ZWQgDQpmb3IgRVY2Ny4gVGhlIHJlc3VsdCBjb25m aXJtcyB5b3VyIGZpbmRpbmdzOg0KDQpgYGANCnJvb3RAZHMxNTovc3J2L3N0b3JhZ2UvYnVp bGQjIA0KTERfTElCUkFSWV9QQVRIPSRQV0QvZ2xpYmMtMi4zNC1wbHVzLXBhdGNoLWV2Njcg L2Jpbi9iYXNoDQpGbG9hdGluZyBwb2ludCBleGNlcHRpb24NCmBgYA0KDQpDaGVlcnMsDQpG cmFuaw0K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to John Paul Adrian Glaubitz on Wed Dec 21 02:00:01 2022
    Hello!

    On 12/15/22 09:09, John Paul Adrian Glaubitz wrote:
    If your glibc fails with Floating Point exception, I fear there might be
    a second bug hiding somewhere which we need to bisect as well. This is particularly annoying since we would have to apply the above diff for
    every bisecting step.

    FWIW, I'm still working on this issue and made some progress.

    Apparently, the segfault was fixed somewhere in the 2.36 development
    cycle but on the other hand, the floating point exception issue
    was introduced.

    Adrian

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to All on Wed Dec 21 18:00:01 2022
    Hello!

    I have not been able to identify the commit that introduced the floating point issue. However, I seem to have found what fixes the segfault properly and also another fix for a third problem, see below.

    FWIW, Adhemeveral told me he would be looking into the glibc issues on alpha in the following days. Currently, I am out of ideas myself.

    Adrian

    ===============================================================================

    Issue:

    (sid-alpha-sbuild)glaubitz@nofan:~/glibc-git/build$ LD_LIBRARY_PATH=/home/glaubitz/glibc-git/build /bin/bash
    /bin/bash: symbol lookup error: /home/glaubitz/glibc-git/build/libc.so.6.1: undefined symbol: _dl_audit_preinit, version GLIBC_PRIVATE
    (sid-alpha-sbuild)glaubitz@nofan:~/glibc-git/build$

    Fixed by:

    commit 144761540a1e40b85997d195d9a226a500531dc9
    Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
    Date: Thu Jan 13 18:04:49 2022 -0300

    elf: Remove LD_USE_LOAD_BIAS

    It is solely for prelink with PIE executables [1].

    [1] https://sourceware.org/legacy-ml/libc-hacker/2003-11/msg00127.html

    Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>

    Issue:

    (sid-alpha-sbuild)glaubitz@nofan:~/glibc-git/build$ LD_LIBRARY_PATH=/home/glaubitz/glibc-git/build /bin/bash
    Segmentation fault
    (sid-alpha-sbuild)glaubitz@nofan:~/glibc-git/build$

    Fixed by:

    commit 0b98a8748759e88b58927882a8714109abe0a2d6
    Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
    Date: Thu Jul 22 17:10:57 2021 -0300

    elf: Add _dl_audit_preinit

    It consolidates the code required to call la_preinit audit
    callback.

    Checked on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu.

    Reviewed-by: Florian Weimer <fweimer@redhat.com>

    csu/libc-start.c | 23 +++--------------------
    elf/Versions | 2 +-
    elf/dl-audit.c | 15 +++++++++++++++
    sysdeps/generic/ldsodefs.h | 3 +++
    4 files changed, 22 insertions(+), 21 deletions(-)

    Issue:

    (sid-alpha-sbuild)glaubitz@nofan:~/glibc-git/build$ LD_LIBRARY_PATH=/home/glaubitz/glibc-git/build /bin/bash
    Floating point exception
    (sid-alpha-sbuild)glaubitz@nofan:~/glibc-git/build$

    Introduced by:

    (not found)

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)