Discussion:
Setting a date for the 2.31 branch
(too old to reply)
Nick Clifton
2018-06-14 13:56:21 UTC
Permalink
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
Cary Coutant
2018-06-14 15:15:56 UTC
Permalink
Post by Nick Clifton
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
Nick Clifton
2018-06-15 14:53:37 UTC
Permalink
Hi Cary,
Post by Cary Coutant
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
Vladimir Radosavljevic
2018-06-15 16:10:17 UTC
Permalink
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
Jeff Law
2018-06-14 15:19:49 UTC
Permalink
Post by 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 ?
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
H.J. Lu
2018-06-14 15:25:23 UTC
Permalink
Post by 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 ?
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.
Cary Coutant
2018-06-23 07:52:20 UTC
Permalink
Post by H.J. Lu
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

Maciej W. Rozycki
2018-06-14 18:11:00 UTC
Permalink
Hi Nick,
Post by Nick Clifton
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
Maciej W. Rozycki
2018-06-22 12:29:00 UTC
Permalink
Hi Nick,
Post by Maciej W. Rozycki
Post by Nick Clifton
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
Matthias Klose
2018-06-15 09:29:49 UTC
Permalink
Post by 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
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
Eric Botcazou
2018-06-15 09:35:07 UTC
Permalink
Post by Matthias Klose
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
Maciej W. Rozycki
2018-06-15 09:57:31 UTC
Permalink
Post by Matthias Klose
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
Maciej W. Rozycki
2018-06-15 16:15:30 UTC
Permalink
Post by Matthias Klose
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
Alan Modra
2018-06-18 02:13:59 UTC
Permalink
Post by Maciej W. Rozycki
Post by Matthias Klose
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
$ 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
Maciej W. Rozycki
2018-06-20 13:29:02 UTC
Permalink
Post by Alan Modra
Post by Maciej W. Rozycki
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
Maciej W. Rozycki
2018-06-16 15:25:58 UTC
Permalink
Post by Maciej W. Rozycki
Post by Matthias Klose
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
Alan Modra
2018-06-18 02:04:05 UTC
Permalink
Post by Matthias Klose
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 ?
Post by Matthias Klose
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.
Post by Matthias Klose
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.
Post by Matthias Klose
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-ifunc/ifunc.exp ...
FAIL: Build pr23169a
FAIL: Build pr23169d
Testsuite problem again.
Post by Matthias Klose
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
Jim Wilson
2018-06-18 19:21:16 UTC
Permalink
Post by Matthias Klose
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
Continue reading on narkive:
Loading...