Setting a date for the 2.31 branch

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Setting a date for the 2.31 branch

Nick Clifton
Hi Guys,

  The last binutils release was in January, so if we want to keep a 6
  month cadence then then next release should be in July.  With my
  Fedora hat on though, it would be very convenient if the next release
  happened before July 11, as that is when the next mass rebuild will
  happen.  Thus I am considering creating the branch a little bit early,
  say June 23 (a Saturday) in order to give enough time for testing and
  bug fixing.

  How would this fit in with your plans ?  A branch on the 23rd would
  give us another week to add in any new features that we want in the
  2.31 release.  This is not a lot of time, I know, but I do not think
  that there are big changes currently in the pipeline.  Are there ?

Cheers
  Nick


 
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Cary Coutant-3
>   The last binutils release was in January, so if we want to keep a 6
>   month cadence then then next release should be in July.  With my
>   Fedora hat on though, it would be very convenient if the next release
>   happened before July 11, as that is when the next mass rebuild will
>   happen.  Thus I am considering creating the branch a little bit early,
>   say June 23 (a Saturday) in order to give enough time for testing and
>   bug fixing.
>
>   How would this fit in with your plans ?  A branch on the 23rd would
>   give us another week to add in any new features that we want in the
>   2.31 release.  This is not a lot of time, I know, but I do not think
>   that there are big changes currently in the pipeline.  Are there ?

The one major bit of new functionality I'm aware of on the horizon is
the nanoMIPS port. Even if those patches were to surface today,
though, it would probably be unrealistic to think they would make it
in by 6/23. If we want that port in 2.31, we'd probably have to delay
the release longer than you'd like. You may want to check with them to
see if they were hoping that feature would make it into this next
release.

-cary
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Jeff Law
In reply to this post by Nick Clifton
On 06/14/2018 07:56 AM, Nick Clifton wrote:

> Hi Guys,
>
>   The last binutils release was in January, so if we want to keep a 6
>   month cadence then then next release should be in July.  With my
>   Fedora hat on though, it would be very convenient if the next release
>   happened before July 11, as that is when the next mass rebuild will
>   happen.  Thus I am considering creating the branch a little bit early,
>   say June 23 (a Saturday) in order to give enough time for testing and
>   bug fixing.
>
>   How would this fit in with your plans ?  A branch on the 23rd would
>   give us another week to add in any new features that we want in the
>   2.31 release.  This is not a lot of time, I know, but I do not think
>   that there are big changes currently in the pipeline.  Are there ?
So I think it's largely in your hands.  If I put my FSF hat on, I think
we're getting enough broad testing from my system that I'm confident the
trunk builds and works on a large number of native and embedded targets.

If I put my Fedora hat on, the concern is the deeper testing on the
Fedora targets.  We're not getting that deep testing of x86, ppc, s390,
aarch64, arm.  But we haven't really ever gotten that deep testing prior
to updating in Fedora.  So I don't think that should be a blocking issue.

I think it really comes down to whether or not you think you've got the
bandwidth to get a release out the door, get Fedora updated and deal
with any fallout from the upcoming mass rebuilds.

jeff
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

H.J. Lu-30
In reply to this post by Nick Clifton
On Thu, Jun 14, 2018 at 6:56 AM, Nick Clifton <[hidden email]> wrote:

> Hi Guys,
>
>   The last binutils release was in January, so if we want to keep a 6
>   month cadence then then next release should be in July.  With my
>   Fedora hat on though, it would be very convenient if the next release
>   happened before July 11, as that is when the next mass rebuild will
>   happen.  Thus I am considering creating the branch a little bit early,
>   say June 23 (a Saturday) in order to give enough time for testing and
>   bug fixing.
>
>   How would this fit in with your plans ?  A branch on the 23rd would
>   give us another week to add in any new features that we want in the
>   2.31 release.  This is not a lot of time, I know, but I do not think
>   that there are big changes currently in the pipeline.  Are there ?
>

Gold still doesn't support CET:

https://sourceware.org/bugzilla/show_bug.cgi?id=22914
https://sourceware.org/bugzilla/show_bug.cgi?id=22915


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Maciej W. Rozycki-2
In reply to this post by Nick Clifton
Hi Nick,

>   How would this fit in with your plans ?  A branch on the 23rd would
>   give us another week to add in any new features that we want in the
>   2.31 release.  This is not a lot of time, I know, but I do not think
>   that there are big changes currently in the pipeline.  Are there ?

 FYI, I'd like to have PR ld/21375 fixed in 2.31, however I think I'll
have plenty of time to make it without asking for a delay.

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Matthias Klose-6
In reply to this post by Nick Clifton
On 14.06.2018 15:56, Nick Clifton wrote:

> Hi Guys,
>
>    The last binutils release was in January, so if we want to keep a 6
>    month cadence then then next release should be in July.  With my
>    Fedora hat on though, it would be very convenient if the next release
>    happened before July 11, as that is when the next mass rebuild will
>    happen.  Thus I am considering creating the branch a little bit early,
>    say June 23 (a Saturday) in order to give enough time for testing and
>    bug fixing.
>
>    How would this fit in with your plans ?  A branch on the 23rd would
>    give us another week to add in any new features that we want in the
>    2.31 release.  This is not a lot of time, I know, but I do not think
>    that there are big changes currently in the pipeline.  Are there ?
>
> Cheers
>    Nick
>
>
>    
>

here are test results for a trunk build from 20180613:
https://buildd.debian.org/status/package.php?p=binutils&suite=experimental

only x86 and hppa pass without failures, and I didn't quote the mips* failures,
because there are so many.

no failures:
amd64, i386, hppa, hurd-i386,

arm64:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-aarch64/aarch64-elf.exp ...
FAIL: ld-aarch64/ifunc-9

armel:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/tls.exp ...
FAIL: Build pr22263-1

armhf:
unning /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/shared.exp ...
XPASS: Run pr19719 fun undefined
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/tls.exp ...
FAIL: Build pr22263-1
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elfvsb/elfvsb.exp ...
XPASS: visibility (hidden_undef) (non PIC)
XPASS: visibility (hidden_undef) (non PIC, load offset)
XPASS: visibility (hidden_undef) (PIC main, non PIC so)
XPASS: visibility (protected_undef) (non PIC)
XPASS: visibility (protected_undef) (non PIC, load offset)
XPASS: visibility (protected_undef) (PIC main, non PIC so)

mips: 74 fails
mips64el: 490 fails
mipsel: 74 fails

ppc64el:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-ifunc/ifunc.exp ...
FAIL: Build pr23169a
FAIL: Build pr23169b
FAIL: Build pr23169c
FAIL: Build pr23169d
FAIL: Build pr23169e
FAIL: Build pr23169f

s390x:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/indirect.exp ...
FAIL: Run indirect5 1
FAIL: Run indirect5 2
FAIL: indirect5a dynsym
FAIL: indirect5b dynsym
FAIL: Run indirect5 3
FAIL: Run indirect5 4
FAIL: indirect5c dynsym
FAIL: indirect5d dynsym
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/shared.exp ...
FAIL: Run pr21964-4
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/tls.exp ...
FAIL: Build pr22263-1
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-ifunc/ifunc.exp ...
FAIL: Build pr23169a
FAIL: Build pr23169c
FAIL: Build pr23169d
FAIL: Build pr23169f
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-s390/s390.exp ...
FAIL: TLS -fpic -shared transitions

alpha:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/shared.exp ...
FAIL: DT_TEXTREL map file warning
FAIL: Build libpr9676-4a.so
FAIL: Build libpr9679.so
FAIL: Build rdynamic-1
FAIL: Build dynamic-1
ERROR: /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/pr19073.s: compilation failed
FAIL: Build libpr19073.so
FAIL: Run with pr11138-2.c libpr11138-1.so
FAIL: Run with libpr11138-1.so pr11138-2.c
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/tls.exp ...
FAIL: Build pr22263-1
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elfvers/vers.exp ...
FAIL: vers30
FAIL: vers31
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-plugin/lto.exp ...
FAIL: Build pr22983
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-plugin/plugin.exp ...
FAIL: plugin claimfile lost symbol
FAIL: plugin claimfile replace symbol
FAIL: plugin claimfile resolve symbol
FAIL: plugin claimfile lost symbol with source
FAIL: plugin claimfile replace symbol with source
FAIL: plugin claimfile resolve symbol with source
FAIL: plugin 2 with source lib
FAIL: load plugin 2 with source
FAIL: plugin 3 with source lib
FAIL: load plugin 3 with source

ia64:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/binutils.exp ...
FAIL: strip -z relro (relro1)
FAIL: strip -z relro -shared (relro1)
FAIL: objcopy -z relro (relro1)
FAIL: objcopy -z relro -shared (relro1)
FAIL: objcopy -z relro (tdata1)
FAIL: objcopy -shared -z relro (tdata1)
FAIL: objcopy -z relro (tdata2)
FAIL: objcopy -shared -z relro (tdata2)
FAIL: objcopy -z relro (tdata3)
FAIL: objcopy -shared -z relro (tdata3)
FAIL: objcopy -shared -z relro (tbss1)
FAIL: objcopy -shared -z relro (tbss2)
FAIL: objcopy -shared -z relro (tbss3)
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/elf.exp ...
FAIL: ld-elf/pr16322
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/indirect.exp ...
FAIL: Run with libpr18720c.so 1
FAIL: Run with libpr18720c.so 2
FAIL: Run with libpr18720c.so 3
FAIL: Run with libpr18720c.so 4
FAIL: Run with libpr18720c.so 5
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/shared.exp ...
FAIL: DT_TEXTREL map file warning
FAIL: Build pr20995-2.so
FAIL: Build rdynamic-1
FAIL: Build dynamic-1
ERROR:  tmpdir/pr22269-1.s: assembly failed
FAIL: Run pr18718
FAIL: Run pr18718 (-z now)
FAIL: Run pr18718 with PIE (1)
FAIL: Run pr18718 with PIE (2)
FAIL: Run pr18718 with PIE (3)
FAIL: Run pr18718 with PIE (4)
FAIL: Run pr18718 with PIC (1)
FAIL: Run pr18718 with PIC (2)
FAIL: Run pr18718 with PIC (3)
FAIL: Run pr18718 with PIC (4)
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/tls.exp ...
ERROR:  tmpdir/pr22263-1a.s: assembly failed
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elfvsb/elfvsb.exp ...
FAIL: visibility (hidden_weak)
FAIL: visibility (hidden_weak) (PIC main)
FAIL: visibility (protected_weak)
FAIL: visibility (protected_weak) (PIC main)
FAIL: weak hidden symbol DSO first

m68k:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/dwarf.exp ...
FAIL: Handle no DWARF information
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/eh-group.exp ...
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/elf.exp ...
Unsupported ioctl: cmd=0x5441
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/indirect.exp ...
FAIL: Run indirect5 3
FAIL: Run indirect5 4
FAIL: Run indirect6 3
FAIL: Run indirect6 4
FAIL: indirect5c dynsym
FAIL: indirect5d dynsym
FAIL: indirect6c dynsym
FAIL: indirect6d dynsym
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/shared.exp ...
FAIL: DT_TEXTREL map file warning
FAIL: pr20995
FAIL: pr20995-2
FAIL: Run pr2404 with PIE
FAIL: Run pr2404 with PIE (-z now)
FAIL: Run pr19719 fun undefined
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/tls.exp ...
FAIL: Build pr22263-1
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-m68k/m68k.exp ...
FAIL: ld-m68k/tls-gd-2
FAIL: ld-m68k/tls-gd-ie-1
FAIL: ld-m68k/tls-ie-1
FAIL: ld-m68k/tls-ld-1

powerpc:
Running /«PKGBUILDDIR»/ld/testsuite/ld-elf/shared.exp ...
FAIL: Run with pr11138-2.c libpr11138-1.so
FAIL: Run with libpr11138-1.so pr11138-2.c
Running /«PKGBUILDDIR»/ld/testsuite/ld-gc/gc.exp ...
FAIL: Check --gc-section
FAIL: Check --gc-section/-q
FAIL: Check --gc-section/-r/-e
FAIL: Check --gc-section/-r/-u
Running /«PKGBUILDDIR»/ld/testsuite/ld-ifunc/ifunc.exp ...
FAIL: Build pr23169a
FAIL: Build pr23169d
FAIL: Run pr23169a
FAIL: Run pr23169b
FAIL: Run pr23169c
FAIL: Run pr23169d
FAIL: Run pr23169e
FAIL: Run pr23169f

ppc64:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-ifunc/ifunc.exp ...
FAIL: Build pr23169a
FAIL: Build pr23169d
FAIL: Run pr18841 with libpr18841b.so
FAIL: Run pr18841 with libpr18841c.so
FAIL: Run pr18841 with libpr18841bn.so (-z now)
FAIL: Run pr18841 with libpr18841cn.so (-z now)

riscv64:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/elf.exp ...
FAIL: PIE PR ld/14525
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/indirect.exp ...
FAIL: Run indirect5 1
FAIL: Run indirect5 2
FAIL: indirect5a dynsym
FAIL: indirect5b dynsym
FAIL: Run indirect5 3
FAIL: Run indirect5 4
FAIL: indirect5c dynsym
FAIL: indirect5d dynsym
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/shared.exp ...
FAIL: Run pr21964-4
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/tls.exp ...
FAIL: Build pr22263-1
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-scripts/size.exp ...
FAIL: ld-scripts/size-1

sh4:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/dwarf.exp ...
FAIL: Handle no DWARF information
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/elf.exp ...
Unsupported ioctl: cmd=0x5441
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/indirect.exp ...
FAIL: Run indirect5 3
FAIL: Run indirect5 4
FAIL: indirect5c dynsym
FAIL: indirect5d dynsym
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/shared.exp ...
FAIL: pr20995
FAIL: pr20995-2
FAIL: Build pr22269-1
FAIL: Run pr19579
FAIL: Run pr19579 (-z now)
FAIL: Run pr19719 fun undefined
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/tls.exp ...
FAIL: Build pr22263-1
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-plugin/lto.exp ...
FAIL: PR ld/12760

sparc64:
Version /<<PKGBUILDDIR>>/builddir-single/binutils/objcopy 2.30.52.20180613
FAIL: binutils-all/strip-14
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-sparc/sparc.exp ...
ERROR: /<<PKGBUILDDIR>>/ld/testsuite/ld-sparc/gotop-hidden.c: compilation failed
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Eric Botcazou-3
> Running /<<PKGBUILDDIR>>/ld/testsuite/ld-sparc/sparc.exp ...
> ERROR: /<<PKGBUILDDIR>>/ld/testsuite/ld-sparc/gotop-hidden.c: compilation
> failed

What's the error for this one?

--
Eric Botcazou
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Maciej W. Rozycki-2
In reply to this post by Matthias Klose-6
On Fri, 15 Jun 2018, Matthias Klose wrote:

> mips: 74 fails
> mips64el: 490 fails
> mipsel: 74 fails

 Yeah, the framework for compiled MIPS tests is broken because you're
probably the only person who runs them regularly (for the MIPS target).  
I can't promise I will be able to find time to fix them, there are more
urgent issues to address.  Sorry.

 Otherwise there's a single LD test failure only:

FAIL: DT_TEXTREL map file warning

which IIRC is just a case to be KFAILed, but I'll double-check.

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Nick Clifton
In reply to this post by Cary Coutant-3
Hi Cary,

> The one major bit of new functionality I'm aware of on the horizon is
> the nanoMIPS port. Even if those patches were to surface today,
> though, it would probably be unrealistic to think they would make it
> in by 6/23. If we want that port in 2.31, we'd probably have to delay
> the release longer than you'd like. You may want to check with them to
> see if they were hoping that feature would make it into this next
> release.

To whom should I speak in order to find out more about their timelines ?

Cheers
  Nick


Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Vladimir Radosavljevic-2
Hi Nick and Cary,

There is no need to delay the release, let's plan to get nanoMIPS
upstreamed for the 2.32 release.

Regards,
Vladimir
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Maciej W. Rozycki-2
In reply to this post by Maciej W. Rozycki-2
On Fri, 15 Jun 2018, Maciej W. Rozycki wrote:

>  Otherwise there's a single LD test failure only:
>
> FAIL: DT_TEXTREL map file warning
>
> which IIRC is just a case to be KFAILed, but I'll double-check.

 Indeed, for sections which have dynamic relocations attached the MIPS
backend sets SHF_WRITE, in `mips_elf_create_dynamic_relocation', yielding:

$ readelf -S textrel.so | grep rodata
  [ 8] .rodata           PROGBITS        00000254 000254 000004 00  WA  0   0  1
$

 This came from commit 7403cb6305f5 ("PATCH for N32 ABI"),
<https://sourceware.org/ml/binutils/1999-q2/msg00375.html>, i.e. for all
practical purposes it has been there since forever, and therefore I think
it can be considered a part of the ABI and the test case considered
irrelevant for MIPS targets.

 Alan, since you've done significant work in this area with commit
63c1f59d6655 ("readonly_dynrelocs") and asked there for maintainer's
attention -- do you agree with my conclusion?

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Maciej W. Rozycki-2
In reply to this post by Maciej W. Rozycki-2
On Fri, 15 Jun 2018, Maciej W. Rozycki wrote:

> On Fri, 15 Jun 2018, Matthias Klose wrote:
>
> > mips: 74 fails
> > mips64el: 490 fails
> > mipsel: 74 fails
>
>  Yeah, the framework for compiled MIPS tests is broken because you're
> probably the only person who runs them regularly (for the MIPS target).  
> I can't promise I will be able to find time to fix them, there are more
> urgent issues to address.  Sorry.

 FYI, I ran native `mips-linux-gnu' (o32) and `mips64-linux-gnu' (n32)
testing and each scored 30 FAILs, so there's something specific to your
configuration that makes the figures look worse with your system.  
Especially the high number of failures with the 64-bit configuration
indicates a possibility of a gross error.  I suggest that you look into it
and see if there is anything obvious reported in the relevant .log file.

 For the record the failures I have observed are:

FAIL: Run indirect5 1
FAIL: Run indirect5 2
FAIL: indirect5a dynsym
FAIL: indirect5b dynsym
FAIL: Run indirect5 3
FAIL: Run indirect5 4
FAIL: Run indirect6 3
FAIL: Run indirect6 4
FAIL: indirect5c dynsym
FAIL: indirect5d dynsym
FAIL: indirect6c dynsym
FAIL: indirect6d dynsym
FAIL: DT_TEXTREL map file warning
FAIL: Build libpr16496b.so
FAIL: Run pr2404 with PIE
FAIL: Run pr2404 with PIE (-z now)
FAIL: Run pr21964-4
FAIL: Build pr22263-1
FAIL: vers24a
FAIL: vers24b
FAIL: vers24c
FAIL: --gc-sections with --defsym
FAIL: --gc-sections with KEEP
FAIL: --gc-sections with __start_SECTIONNAME
FAIL: PR ld/13229
FAIL: ld-plugin/lto-3r
FAIL: ld-plugin/lto-5r
FAIL: PR ld/19317 (2)
FAIL: shared (non PIC)
FAIL: shared (PIC main, non PIC so)

 Of these the indirect test failures will I believe go away once PR
ld/21805 has been fixed, which in turn requires PR ld/21375 to be fixed
first.  I'm currently working on the latter issue and I do hope to get
both covered by the deadline set by Nick.

 Some of the remaining failures are due to (the lack of suitable) GAS
options used with `dummy.s' assembly causing the ABI recorded with the
resulting object file to be incompatible with the ABI of compiled objects
used in the same test.  This is a complex issue to fix as the GAS options
to be used depend on how the compiler has been configured and cannot be
simply inferred from the target triplet.  They would have to be determined
somehow at the time testing is invoked.

 The simplest solution could be running GAS with the GCC driver, but this
is I believe currently not supported by `run_dump_test' which those tests
use.  Alternatively the driver could be used in its verbose mode with a
dummy assembly and the options extracted somehow from the GAS invocation
line reported.

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Alan Modra-3
In reply to this post by Matthias Klose-6
On Fri, Jun 15, 2018 at 11:29:49AM +0200, Matthias Klose wrote:
> ppc64el:
> Running /<<PKGBUILDDIR>>/ld/testsuite/ld-ifunc/ifunc.exp ...
> FAIL: Build pr23169a
> FAIL: Build pr23169b
> FAIL: Build pr23169c
> FAIL: Build pr23169d
> FAIL: Build pr23169e
> FAIL: Build pr23169f

This is a testsuite problem.  Expected readelf output is that for x86
which lacks the localentry annotation for functions on ppc64le.
pr23169a and pr23169d expect that "func" is changed from an ifunc to a
normal function, which is a lie, and I think unnecessary as
demonstrated by the fact that ppc64le and ppc64 pass actually running
these tests.  Did someone OK HJ's patch at
https://sourceware.org/ml/binutils/2018-05/msg00140.html ?

> powerpc:
> Running /«PKGBUILDDIR»/ld/testsuite/ld-elf/shared.exp ...
> FAIL: Run with pr11138-2.c libpr11138-1.so
> FAIL: Run with libpr11138-1.so pr11138-2.c
> Running /«PKGBUILDDIR»/ld/testsuite/ld-gc/gc.exp ...
> FAIL: Check --gc-section
> FAIL: Check --gc-section/-q
> FAIL: Check --gc-section/-r/-e
> FAIL: Check --gc-section/-r/-u
> Running /«PKGBUILDDIR»/ld/testsuite/ld-ifunc/ifunc.exp ...

I don't see any of the above.

> FAIL: Build pr23169a
> FAIL: Build pr23169d
> FAIL: Run pr23169a
> FAIL: Run pr23169b
> FAIL: Run pr23169c
> FAIL: Run pr23169d
> FAIL: Run pr23169e
> FAIL: Run pr23169f

Testsuite problem, and possibly some ppc32 breakage.

> ppc64:
> Running /<<PKGBUILDDIR>>/ld/testsuite/ld-ifunc/ifunc.exp ...
> FAIL: Build pr23169a
> FAIL: Build pr23169d

Testsuite problem again.

> FAIL: Run pr18841 with libpr18841b.so
> FAIL: Run pr18841 with libpr18841c.so
> FAIL: Run pr18841 with libpr18841bn.so (-z now)
> FAIL: Run pr18841 with libpr18841cn.so (-z now)

I don't see these.

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Alan Modra-3
In reply to this post by Maciej W. Rozycki-2
On Fri, Jun 15, 2018 at 05:15:30PM +0100, Maciej W. Rozycki wrote:

> On Fri, 15 Jun 2018, Maciej W. Rozycki wrote:
>
> >  Otherwise there's a single LD test failure only:
> >
> > FAIL: DT_TEXTREL map file warning
> >
> > which IIRC is just a case to be KFAILed, but I'll double-check.
>
>  Indeed, for sections which have dynamic relocations attached the MIPS
> backend sets SHF_WRITE, in `mips_elf_create_dynamic_relocation', yielding:
>
> $ readelf -S textrel.so | grep rodata
>   [ 8] .rodata           PROGBITS        00000254 000254 000004 00  WA  0   0  1
> $
>
>  This came from commit 7403cb6305f5 ("PATCH for N32 ABI"),
> <https://sourceware.org/ml/binutils/1999-q2/msg00375.html>, i.e. for all
> practical purposes it has been there since forever, and therefore I think
> it can be considered a part of the ABI and the test case considered
> irrelevant for MIPS targets.
>
>  Alan, since you've done significant work in this area with commit
> 63c1f59d6655 ("readonly_dynrelocs") and asked there for maintainer's
> attention -- do you agree with my conclusion?

Yes, and I'm quite happy you are the one working on mips.  ;)

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Jim Wilson-2
In reply to this post by Matthias Klose-6
On 06/15/2018 02:29 AM, Matthias Klose wrote:

> riscv64:
> Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/elf.exp ...
> FAIL: PIE PR ld/14525
> Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/indirect.exp ...
> FAIL: Run indirect5 1
> FAIL: Run indirect5 2
> FAIL: indirect5a dynsym
> FAIL: indirect5b dynsym
> FAIL: Run indirect5 3
> FAIL: Run indirect5 4
> FAIL: indirect5c dynsym
> FAIL: indirect5d dynsym
> Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/shared.exp ...
> FAIL: Run pr21964-4
> Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/tls.exp ...
> FAIL: Build pr22263-1
> Running /<<PKGBUILDDIR>>/ld/testsuite/ld-scripts/size.exp ...
> FAIL: ld-scripts/size-1

I see only 8 failures on Fedora and it is a slightly different set.  I
don't have a debian system running yet, but I hope to set one up for my
use in a few weeks and can look at debian binutils/gcc failures then.

RISC-V is a new target.  I fixed all of the binutils and gas unexpected
failures.  I'm still working my way through the linker unexpected
failures.  Most of the remaining Fedora linker failures are PIE related.
  The last one, size-1, is a problem with alignment and section sizes,
which gets complicated on RISC-V due to the fact that we delete
instructions during relaxation.  This one didn't look important, we just
end up with some extra padding in a section at the end.  The PIE
failures need to be fixed, but it may take some time.  I have an
unfinished patch that fixes 4 of these cross, but didn't work native.
It looks like some kind of got/plt issue which I had trouble debugging
with printf, so I made a detour to try to get a minimal gdb working so I
can use it to debug my linker patch and will get back to fixing linker
testsuite failures at some point.

Jim

Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Maciej W. Rozycki-2
In reply to this post by Alan Modra-3
On Sun, 17 Jun 2018, Alan Modra wrote:

> >  Alan, since you've done significant work in this area with commit
> > 63c1f59d6655 ("readonly_dynrelocs") and asked there for maintainer's
> > attention -- do you agree with my conclusion?
>
> Yes, and I'm quite happy you are the one working on mips.  ;)

 Fixed with commit a4eb69274d3b ("MIPS/LD/testsuite: XFAIL DT_TEXTREL map
file warning test") then.  Thank you for your input and the kind words.

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Maciej W. Rozycki-2
In reply to this post by Maciej W. Rozycki-2
Hi Nick,

On Thu, 14 Jun 2018, Maciej W. Rozycki wrote:

> >   How would this fit in with your plans ?  A branch on the 23rd would
> >   give us another week to add in any new features that we want in the
> >   2.31 release.  This is not a lot of time, I know, but I do not think
> >   that there are big changes currently in the pipeline.  Are there ?
>
>  FYI, I'd like to have PR ld/21375 fixed in 2.31, however I think I'll
> have plenty of time to make it without asking for a delay.

 I have removed the 2.31 milestone from PR ld/21375 and PR/21805 and I
won't be including fixes (both of which I have almost ready, only test
cases are missing) in the upcoming 2.31 release.

 The reason is in the course of PR ld/21375 fix verification I have
stumbled across a glibc dynamic loader bug, now glibc BZ #23307, in the
course of the fix of which I concluded a libc ABI bump is required,
marking (proper) absolute symbol support a new feature.  Given that the
PR ld/21375 fix relies on it, we need at least one released glibc
version to be available before we can include the fix in our release.  

 And the upcoming glibc release 2.28 is scheduled Aug 1st, which means
we can only include it in our 2.32 release expected to happen early next
year.  There is only as little time left before glibc sources have
become frozen for the 2.28 release as until the end of Jun, however I do
hope the fix for BZ #23307 makes it as I have already posted it for
review and it's straightforward.  The only real issue with it I can
imagine is to decide whether the ABI bump is justified or not.

 This means I have no specific plans for the upcoming 2.31 release and
I'm happy with you branching the tree tomorrow.  I'll continue pushing
other outstanding fixes of course, but I don't think any of them is
critical enough to have it included in 2.31.

 BTW, can you or someone else please add a 2.32 milestone to our
bugzilla, which is something I have no permission to do myself?  I want
these two bugs to target 2.32 and actually push fixes to master as soon
as 2.31 has branched (obviously not before the glibc side has been
accepted though).

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: Setting a date for the 2.31 branch

Cary Coutant-3
In reply to this post by H.J. Lu-30
> Gold still doesn't support CET:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=22914
> https://sourceware.org/bugzilla/show_bug.cgi?id=22915

This is in now (at least for x86-64). I think gold is ready for the 2.31 branch.

-cary