This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Setting a date for the 2.31 branch
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