test results with the 2.35 branch for several architectures

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

test results with the 2.35 branch for several architectures

Matthias Klose-6
With a snapshot taken from the 3.35 on 20200708, I see test failures on some
targets, complete logs at
https://buildd.debian.org/status/package.php?p=binutils

no test failures on amd64, amd64-x32, ppc64el, sparc64.

Matthias


aarch64:

Running /<<PKGBUILDDIR>>/ld/testsuite/ld-aarch64/aarch64-elf.exp ...
FAIL: ld-aarch64/tls-relax-gdesc-le-now

armel:

Running /<<PKGBUILDDIR>>/ld/testsuite/ld-arm/arm-elf.exp ...
FAIL: Thumb only PLT and GOT
FAIL: Thumb only PLT and GOT LSB Symbol

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

Running /<<PKGBUILDDIR>>/ld/testsuite/ld-ifunc/ifunc.exp ...
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)
FAIL: Run pr23169a
FAIL: Run pr23169d

armhf:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/shared.exp ...
XPASS: Run pr19719 fun undefined

Running /<<PKGBUILDDIR>>/ld/testsuite/ld-ifunc/ifunc.exp ...
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)
FAIL: Run pr23169a
FAIL: Run pr23169d

i386/i686:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-i386/i386.exp ...
FAIL: Run pr19031
FAIL: Run got1
FAIL: Undefined weak symbol (-fPIE -no-pie)
FAIL: Undefined weak symbol (-fPIE -pie)

mips64el:
131 failures, see
https://buildd.debian.org/status/fetch.php?pkg=binutils&arch=mips64el&ver=2.34.90.20200706-1&stamp=1594128199&raw=1

mipsel:
101 failures, see
https://buildd.debian.org/status/fetch.php?pkg=binutils&arch=mipsel&ver=2.34.90.20200706-1&stamp=1594122742&raw=1

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 pr23169c
FAIL: Build pr23169f

alpha:
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

hurd-i386:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-i386/no-plt.exp ...
FAIL: Run pr20253-1a

m68k:

Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/dwarf.exp ...
FAIL: Handle no DWARF information
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: pr22269-1 (static pie undefined weak)
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-gc/gc.exp ...
FAIL: Check --gc-section
FAIL: Check --gc-section/-q
FAIL: Check --gc-section/-r/-e
FAIL: Check --gc-section/-r/-u


powerpc64:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-ifunc/ifunc.exp ...
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/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


sh4:
Running /<<PKGBUILDDIR>>/ld/testsuite/ld-elf/dwarf.exp ...
FAIL: Handle no DWARF information
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: pr22269-1 (static pie undefined weak)
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


Reply | Threaded
Open this post in threaded view
|

Re: test results with the 2.35 branch for several architectures

Sourceware - binutils list mailing list
On Wed, Jul 8, 2020 at 7:35 AM Matthias Klose <[hidden email]> wrote:

>
> With a snapshot taken from the 3.35 on 20200708, I see test failures on some
> targets, complete logs at
> https://buildd.debian.org/status/package.php?p=binutils
>
> no test failures on amd64, amd64-x32, ppc64el, sparc64.
>
> i386/i686:
> Running /<<PKGBUILDDIR>>/ld/testsuite/ld-i386/i386.exp ...
> FAIL: Run pr19031
> FAIL: Run got1
> FAIL: Undefined weak symbol (-fPIE -no-pie)
> FAIL: Undefined weak symbol (-fPIE -pie)

I can't reproduce it with GCC 10.

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

Re: test results with the 2.35 branch for several architectures

Jim Wilson-2
In reply to this post by Matthias Klose-6
On Wed, Jul 8, 2020 at 7:35 AM Matthias Klose <[hidden email]> wrote:
> With a snapshot taken from the 3.35 on 20200708, I see test failures on some
> targets, complete logs at
> https://buildd.debian.org/status/package.php?p=binutils

> riscv64:
> 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

This is the usual set of failures.  Though curiously the indirect
tests aren't failing for me on a fedora rawhide system anymore, so
maybe something got fixed somewhere.  The indirect5c and indirect5d
still fail for me on a cross build.

Jim
Reply | Threaded
Open this post in threaded view
|

Re: test results with the 2.35 branch for several architectures

Sourceware - binutils list mailing list
In reply to this post by Matthias Klose-6
On Wed, Jul 08, 2020 at 04:34:51PM +0200, Matthias Klose wrote:
> powerpc:
> 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

I don't see these failures.  Can you show ld.log for these tests?

> powerpc64:
> Running /<<PKGBUILDDIR>>/ld/testsuite/ld-ifunc/ifunc.exp ...
> 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 failures using gcc-7.3.1 on RedHat FC27 or gcc-4.8.5
on FC28 when running the testsuite.  The test does do cross-module
calls from within an ifunc resolver, which is nasty since the called
function may not be relocated.  In this case the called function (zoo)
is just a stub so doesn't need relocating, but on ppc64 the function
descriptor for zoo in the executable won't be relocated at the time
the shared library ifunc resolver runs.  That means the test will fail
if your compiler generates PIEs by default.  I do get segfaults on
FC27 if I compile the executable as a PIE..

HJ, I think I should change the test to use NOPIE_LDFLAGS and
NOPIE_CFLAGS.  That shouldn't affect the original purpose of the test,
which was to ensure proper ifunc dynamic reloc sorting.

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

Re: test results with the 2.35 branch for several architectures

Matthias Klose-6
On 7/9/20 8:32 AM, Alan Modra wrote:
> On Wed, Jul 08, 2020 at 04:34:51PM +0200, Matthias Klose wrote:
>> powerpc:
>> 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
>
> I don't see these failures.  Can you show ld.log for these tests?

FAIL: Check --gc-section
./ld-new   -o tmpdir/gcrexe
-L/build/binutils-WwtG9h/binutils-2.34.90.20200706/ld/testsuite/ld-gc
--gc-sections -q -e main --defsym __stack_chk_fail=0 tmpdir/gc.o
Executing on host: sh -c {./ld-new   -o tmpdir/gcrexe
-L/build/binutils-WwtG9h/binutils-2.34.90.20200706/ld/testsuite/ld-gc
--gc-sections -q -e main --defsym __stack_chk_fail=0 tmpdir/gc.o 2>&1}
/dev/null ld.tmp (timeout = 300)
spawn [open ...]
/build/binutils-WwtG9h/binutils-2.34.90.20200706/builddir-single/ld/../binutils/nm-new
  tmpdir/gcrexe >tmpdir/nm.out
Executing on host: sh -c
{/build/binutils-WwtG9h/binutils-2.34.90.20200706/builddir-single/ld/../binutils/nm-new
  tmpdir/gcrexe 2>ld.stderr}  /dev/null tmpdir/nm.out (timeout = 300)
spawn [open ...]
10020008 D __bss_start
00000000 A __stack_chk_fail
10020008 D _edata
10020008 D _end
100000c0 T main
10020000 D unused_var
100000d0 T used_func
10020004 D used_var
unused section still here
FAIL: Check --gc-section/-q
./ld-new   -o tmpdir/gcrel
-L/build/binutils-WwtG9h/binutils-2.34.90.20200706/ld/testsuite/ld-gc -r
--gc-sections -e main --defsym __stack_chk_fail=0 tmpdir/gc.o
Executing on host: sh -c {./ld-new   -o tmpdir/gcrel
-L/build/binutils-WwtG9h/binutils-2.34.90.20200706/ld/testsuite/ld-gc -r
--gc-sections -e main --defsym __stack_chk_fail=0 tmpdir/gc.o 2>&1}  /dev/null
ld.tmp (timeout = 300)
spawn [open ...]
/build/binutils-WwtG9h/binutils-2.34.90.20200706/builddir-single/ld/../binutils/nm-new
  tmpdir/gcrel >tmpdir/nm.out
Executing on host: sh -c
{/build/binutils-WwtG9h/binutils-2.34.90.20200706/builddir-single/ld/../binutils/nm-new
  tmpdir/gcrel 2>ld.stderr}  /dev/null tmpdir/nm.out (timeout = 300)
spawn [open ...]
00000000 A __stack_chk_fail
00000000 T main
00000000 D unused_var
00000000 T used_func
00000000 D used_var
unused section still here
FAIL: Check --gc-section/-r/-e
./ld-new   -o tmpdir/gcrel
-L/build/binutils-WwtG9h/binutils-2.34.90.20200706/ld/testsuite/ld-gc -r
--gc-sections -u used_func --defsym __stack_chk_fail=0 tmpdir/gc.o
Executing on host: sh -c {./ld-new   -o tmpdir/gcrel
-L/build/binutils-WwtG9h/binutils-2.34.90.20200706/ld/testsuite/ld-gc -r
--gc-sections -u used_func --defsym __stack_chk_fail=0 tmpdir/gc.o 2>&1}
/dev/null ld.tmp (timeout = 300)
spawn [open ...]
/build/binutils-WwtG9h/binutils-2.34.90.20200706/builddir-single/ld/../binutils/nm-new
  tmpdir/gcrel >tmpdir/nm.out
Executing on host: sh -c
{/build/binutils-WwtG9h/binutils-2.34.90.20200706/builddir-single/ld/../binutils/nm-new
  tmpdir/gcrel 2>ld.stderr}  /dev/null tmpdir/nm.out (timeout = 300)
spawn [open ...]
00000000 A __stack_chk_fail
00000000 D unused_var
00000000 T used_func
00000000 D used_var
unused section still here
FAIL: Check --gc-section/-r/-u

>
>> powerpc64:
>> Running /<<PKGBUILDDIR>>/ld/testsuite/ld-ifunc/ifunc.exp ...
>> 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 failures using gcc-7.3.1 on RedHat FC27 or gcc-4.8.5
> on FC28 when running the testsuite.  The test does do cross-module
> calls from within an ifunc resolver, which is nasty since the called
> function may not be relocated.  In this case the called function (zoo)
> is just a stub so doesn't need relocating, but on ppc64 the function
> descriptor for zoo in the executable won't be relocated at the time
> the shared library ifunc resolver runs.  That means the test will fail
> if your compiler generates PIEs by default.  I do get segfaults on
> FC27 if I compile the executable as a PIE..

yes, GCC is configured with --enable-default-pie on both Debian and Ubuntu.

> HJ, I think I should change the test to use NOPIE_LDFLAGS and
> NOPIE_CFLAGS.  That shouldn't affect the original purpose of the test,
> which was to ensure proper ifunc dynamic reloc sorting.
>

Reply | Threaded
Open this post in threaded view
|

Re: test results with the 2.35 branch for several architectures

Sourceware - binutils list mailing list
In reply to this post by Sourceware - binutils list mailing list
On Wed, Jul 8, 2020 at 11:32 PM Alan Modra <[hidden email]> wrote:

>
> On Wed, Jul 08, 2020 at 04:34:51PM +0200, Matthias Klose wrote:
> > powerpc:
> > 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
>
> I don't see these failures.  Can you show ld.log for these tests?
>
> > powerpc64:
> > Running /<<PKGBUILDDIR>>/ld/testsuite/ld-ifunc/ifunc.exp ...
> > 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 failures using gcc-7.3.1 on RedHat FC27 or gcc-4.8.5
> on FC28 when running the testsuite.  The test does do cross-module
> calls from within an ifunc resolver, which is nasty since the called
> function may not be relocated.  In this case the called function (zoo)
> is just a stub so doesn't need relocating, but on ppc64 the function
> descriptor for zoo in the executable won't be relocated at the time
> the shared library ifunc resolver runs.  That means the test will fail
> if your compiler generates PIEs by default.  I do get segfaults on
> FC27 if I compile the executable as a PIE..
>
> HJ, I think I should change the test to use NOPIE_LDFLAGS and
> NOPIE_CFLAGS.  That shouldn't affect the original purpose of the test,
> which was to ensure proper ifunc dynamic reloc sorting.

Sure.


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

Re: test results with the 2.35 branch for several architectures

Sourceware - binutils list mailing list
In reply to this post by Matthias Klose-6
On Thu, Jul 09, 2020 at 12:25:22PM +0200, Matthias Klose wrote:

> On 7/9/20 8:32 AM, Alan Modra wrote:
> > On Wed, Jul 08, 2020 at 04:34:51PM +0200, Matthias Klose wrote:
> >> powerpc:
> >> 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
> >
> > I don't see these failures.  Can you show ld.log for these tests?
>
> 10020008 D __bss_start
> 00000000 A __stack_chk_fail
> 10020008 D _edata
> 10020008 D _end
> 100000c0 T main
> 10020000 D unused_var
> 100000d0 T used_func
> 10020004 D used_var
> unused section still here

Thanks, that's another -fPIE induced fail.  -fPIC/-fPIE on powerpc
-m32 generates code that uses .got2, effectively allowing 64k of GOT
per object file (while -fpic/-fpie only allows 64k of GOT total).
The ppc32 linker doesn't garbage collect .got2 entries due to lack of
any relocs on code accessing .got2 entries.  Without relocs, garbage
collection would need to do code scanning, and I don't think that's a
good idea.

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

pr18841 tests on powerpc64

Sourceware - binutils list mailing list
In reply to this post by Matthias Klose-6
The PR18841 test does cross-module calls from within an ifunc
resolver, which is nasty, and not supported in general since the
called function may not be relocated.  In this case the called
function (zoo) is just a stub so doesn't need relocating, but on ppc64
the function descriptor for zoo in the executable won't be relocated
at the time the shared library ifunc resolver runs.  That means the
test will fail if your compiler generates PIEs by default.

        PR 18841
        * testsuite/ld-ifunc/ifunc.exp: Run pr18841 tests non-pie.

diff --git a/ld/testsuite/ld-ifunc/ifunc.exp b/ld/testsuite/ld-ifunc/ifunc.exp
index 08cc87875c..f67808c266 100644
--- a/ld/testsuite/ld-ifunc/ifunc.exp
+++ b/ld/testsuite/ld-ifunc/ifunc.exp
@@ -559,7 +559,7 @@ run_cc_link_tests [list \
     [list \
  "Build pr18841a.o" \
  "" \
- "" \
+ "$NOPIE_CFLAGS" \
  { pr18841a.c } \
  "" \
  "" \
@@ -687,32 +687,32 @@ run_ld_link_exec_tests [list \
     ] \
     [list \
  "Run pr18841 with libpr18841b.so" \
- "-Wl,--no-as-needed tmpdir/pr18841a.o tmpdir/libpr18841b.so" \
- "" \
+ "$NOPIE_LDFLAGS -Wl,--no-as-needed tmpdir/pr18841a.o tmpdir/libpr18841b.so" \
+ "$NOPIE_CFLAGS" \
  { dummy.c } \
  "pr18841b" \
  "pr18841.out" \
     ] \
     [list \
  "Run pr18841 with libpr18841c.so" \
- "-Wl,--as-needed tmpdir/pr18841a.o tmpdir/libpr18841c.so" \
- "" \
+ "$NOPIE_LDFLAGS -Wl,--as-needed tmpdir/pr18841a.o tmpdir/libpr18841c.so" \
+ "$NOPIE_CFLAGS" \
  { dummy.c } \
  "pr18841c" \
  "pr18841.out" \
     ] \
     [list \
  "Run pr18841 with libpr18841bn.so (-z now)" \
- "-Wl,-z,now -Wl,--no-as-needed tmpdir/pr18841a.o tmpdir/libpr18841bn.so" \
- "" \
+ "$NOPIE_LDFLAGS -Wl,-z,now -Wl,--no-as-needed tmpdir/pr18841a.o tmpdir/libpr18841bn.so" \
+ "$NOPIE_CFLAGS" \
  { dummy.c } \
  "pr18841bn" \
  "pr18841.out" \
     ] \
     [list \
  "Run pr18841 with libpr18841cn.so (-z now)" \
- "-Wl,-z,now -Wl,--as-needed tmpdir/pr18841a.o tmpdir/libpr18841cn.so" \
- "" \
+ "$NOPIE_LDFLAGS -Wl,-z,now -Wl,--as-needed tmpdir/pr18841a.o tmpdir/libpr18841cn.so" \
+ "$NOPIE_CFLAGS" \
  { dummy.c } \
  "pr18841cn" \
  "pr18841.out" \

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

powerpc garbage collect test

Sourceware - binutils list mailing list
In reply to this post by Matthias Klose-6
ld's garbage collection test on powerpc64 catered for old compilers
(pre -mcmodel=medium support), setting options that caused the test to
fail.  Which meant the test wasn't really testing anything.  Get rid
of that old compiler support, and avoid -fPIE fails on ppc32.

        * testsuite/ld-gc/gc.exp: Don't set -mminimal-toc for powerpc64,
        and remove powerpc64 xfail.  Use -fno-PIE for ppc32.

diff --git a/ld/testsuite/ld-gc/gc.exp b/ld/testsuite/ld-gc/gc.exp
index ea3316887e..285e7d1cb5 100644
--- a/ld/testsuite/ld-gc/gc.exp
+++ b/ld/testsuite/ld-gc/gc.exp
@@ -26,9 +26,9 @@ if ![check_gc_sections_available] {
 set cflags "-ffunction-sections -fdata-sections $NOSANTIZE_CFLAGS"
 set objfile "tmpdir/gc.o"
 
-if [istarget powerpc64*-*-*] {
-    # otherwise with -mcmodel=medium gcc we get XPASSes.
-    set cflags "$cflags -mminimal-toc"
+if { [istarget powerpc*-*-*] && ![istarget powerpc64*-*-*] } {
+    # Avoid using .got2 for powerpc -m32
+    set cflags "$cflags $NOPIE_CFLAGS"
 }
 
 if { [istarget m681*-*-*] || [istarget m68hc1*-*-*] } {
@@ -71,9 +71,6 @@ proc test_gc { testname filename linker ldflags} {
  fail $testname
  return
     }
-    #ppc64_elf_gc_mark_hook needs to be taught how to look through
-    #the .toc section to properly mark variable sections for gc.
-    setup_xfail "powerpc64*-*-*"
     if {[info exists nm_output(unused_func)] \
     || [info exists nm_output(unused_var)]} {
  send_log "unused section still here\n"

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

Re: powerpc garbage collect test

Matthias Klose-6
On 7/9/20 3:27 PM, Alan Modra wrote:
> ld's garbage collection test on powerpc64 catered for old compilers
> (pre -mcmodel=medium support), setting options that caused the test to
> fail.  Which meant the test wasn't really testing anything.  Get rid
> of that old compiler support, and avoid -fPIE fails on ppc32.
>
> * testsuite/ld-gc/gc.exp: Don't set -mminimal-toc for powerpc64,
> and remove powerpc64 xfail.  Use -fno-PIE for ppc32.

please could you commit this to the 2.35 branch as well?

Thanks, Matthias
Reply | Threaded
Open this post in threaded view
|

Re: pr18841 tests on powerpc64

Matthias Klose-6
In reply to this post by Sourceware - binutils list mailing list
On 7/9/20 3:26 PM, Alan Modra wrote:

> The PR18841 test does cross-module calls from within an ifunc
> resolver, which is nasty, and not supported in general since the
> called function may not be relocated.  In this case the called
> function (zoo) is just a stub so doesn't need relocating, but on ppc64
> the function descriptor for zoo in the executable won't be relocated
> at the time the shared library ifunc resolver runs.  That means the
> test will fail if your compiler generates PIEs by default.
>
> PR 18841
> * testsuite/ld-ifunc/ifunc.exp: Run pr18841 tests non-pie.


please could you commit this to the 2.35 branch as well?

Thanks, Matthias
Reply | Threaded
Open this post in threaded view
|

Re: powerpc garbage collect test

Sourceware - binutils list mailing list
In reply to this post by Matthias Klose-6
On Mon, Jul 13, 2020 at 03:19:53PM +0200, Matthias Klose wrote:

> On 7/9/20 3:27 PM, Alan Modra wrote:
> > ld's garbage collection test on powerpc64 catered for old compilers
> > (pre -mcmodel=medium support), setting options that caused the test to
> > fail.  Which meant the test wasn't really testing anything.  Get rid
> > of that old compiler support, and avoid -fPIE fails on ppc32.
> >
> > * testsuite/ld-gc/gc.exp: Don't set -mminimal-toc for powerpc64,
> > and remove powerpc64 xfail.  Use -fno-PIE for ppc32.
>
> please could you commit this to the 2.35 branch as well?

Done.

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

Re: pr18841 tests on powerpc64

Sourceware - binutils list mailing list
In reply to this post by Matthias Klose-6
On Mon, Jul 13, 2020 at 03:20:21PM +0200, Matthias Klose wrote:

> On 7/9/20 3:26 PM, Alan Modra wrote:
> > The PR18841 test does cross-module calls from within an ifunc
> > resolver, which is nasty, and not supported in general since the
> > called function may not be relocated.  In this case the called
> > function (zoo) is just a stub so doesn't need relocating, but on ppc64
> > the function descriptor for zoo in the executable won't be relocated
> > at the time the shared library ifunc resolver runs.  That means the
> > test will fail if your compiler generates PIEs by default.
> >
> > PR 18841
> > * testsuite/ld-ifunc/ifunc.exp: Run pr18841 tests non-pie.
>
>
> please could you commit this to the 2.35 branch as well?

and done.

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

Re: test results with the 2.35 branch for several architectures

Maciej W. Rozycki
In reply to this post by Matthias Klose-6
On Wed, 8 Jul 2020, Matthias Klose wrote:

> mips64el:
> 131 failures, see
> https://buildd.debian.org/status/fetch.php?pkg=binutils&arch=mips64el&ver=2.34.90.20200706-1&stamp=1594128199&raw=1

 At least some, and probably most if not all of these are likely due to
this local patch:

dpkg-source: info: applying mips64-default-n64.diff

which I gather switches the default ABI from n32 to n64.  The testsuite is
not prepared for this, especially the generic pieces, but neither are some
MIPS-specific parts.  And in any case to match the change made you need to
update this conditional within that patch as well:

} elseif { [istarget mips64*-*-linux*] } {
    if [istarget *el-*-*] {
        set abi_asflags(o32) -32
        set abi_ldflags(o32) -melf32ltsmip
        set abi_asflags(n64) "-march=from-abi -64"
        set abi_ldflags(n64) -melf64ltsmip
    } else {
        set abi_asflags(o32) -32
        set abi_ldflags(o32) -melf32btsmip
        set abi_asflags(n64) "-march=from-abi -64"
        set abi_ldflags(n64) -melf64btsmip
    }
    set irixemul 0

(in ld/testsuite/ld-mips-elf/mips-elf.exp) to set `n32' flags (which are
no longer nil, due to the ABI not being the default anymore) rather than
`n64' flags (which can now be nil).  Any flags not explicitly set default
to nil.  Yes, this is intentional, to verify the defaults as well.

 Some of the GAS failures are bugs in the respective test cases, which
fail to select an ABI with assembly and just happen to work with both o32
and n32, but not n64.

> mipsel:
> 101 failures, see
> https://buildd.debian.org/status/fetch.php?pkg=binutils&arch=mipsel&ver=2.34.90.20200706-1&stamp=1594122742&raw=1

 This builds natively and therefore I gather these are the usual compiled
test failures.  As I recall a couple are genuine, such as the IFUNC tests,
and many are due to ABI mismatches between object files built with GCC and
ones assembled directly with GAS caused by incompatible code generation
options, as GAS and/or LD defaults are often different from GCC defaults.  
The test framework would have to be updated accordingly for these to work.

 HTH,

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: test results with the 2.35 branch for several architectures

Palmer Dabbelt
In reply to this post by Jim Wilson-2
On Wed, 08 Jul 2020 10:49:25 PDT (-0700), Jim Wilson wrote:

> On Wed, Jul 8, 2020 at 7:35 AM Matthias Klose <[hidden email]> wrote:
>> With a snapshot taken from the 3.35 on 20200708, I see test failures on some
>> targets, complete logs at
>> https://buildd.debian.org/status/package.php?p=binutils
>
>> riscv64:
>> 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
>
> This is the usual set of failures.  Though curiously the indirect
> tests aren't failing for me on a fedora rawhide system anymore, so
> maybe something got fixed somewhere.  The indirect5c and indirect5d
> still fail for me on a cross build.

For the people who aren't familiar with RISC-V: we maintain a list of allowed
test failures over here:
https://github.com/riscv/riscv-gnu-toolchain/tree/master/test/allowlist .
Don't know how well it's pruned any more, though.  They're probably all worth
fixing, but there's only so much time...
Reply | Threaded
Open this post in threaded view
|

Re: test results with the 2.35 branch for several architectures

Matthias Klose-6
In reply to this post by Maciej W. Rozycki
On 7/20/20 1:43 AM, Maciej W. Rozycki wrote:

> On Wed, 8 Jul 2020, Matthias Klose wrote:
>
>> mips64el:
>> 131 failures, see
>> https://buildd.debian.org/status/fetch.php?pkg=binutils&arch=mips64el&ver=2.34.90.20200706-1&stamp=1594128199&raw=1
>
>  At least some, and probably most if not all of these are likely due to
> this local patch:
>
> dpkg-source: info: applying mips64-default-n64.diff
>
> which I gather switches the default ABI from n32 to n64.  The testsuite is
> not prepared for this, especially the generic pieces, but neither are some
> MIPS-specific parts.  And in any case to match the change made you need to
> update this conditional within that patch as well:
>
> } elseif { [istarget mips64*-*-linux*] } {
>     if [istarget *el-*-*] {
> set abi_asflags(o32) -32
> set abi_ldflags(o32) -melf32ltsmip
> set abi_asflags(n64) "-march=from-abi -64"
> set abi_ldflags(n64) -melf64ltsmip
>     } else {
> set abi_asflags(o32) -32
> set abi_ldflags(o32) -melf32btsmip
> set abi_asflags(n64) "-march=from-abi -64"
> set abi_ldflags(n64) -melf64btsmip
>     }
>     set irixemul 0
>
> (in ld/testsuite/ld-mips-elf/mips-elf.exp) to set `n32' flags (which are
> no longer nil, due to the ABI not being the default anymore) rather than
> `n64' flags (which can now be nil).  Any flags not explicitly set default
> to nil.  Yes, this is intentional, to verify the defaults as well.
>
>  Some of the GAS failures are bugs in the respective test cases, which
> fail to select an ABI with assembly and just happen to work with both o32
> and n32, but not n64.

Thanks for looking at this, this change was requested by one of the Debian MIPS
porters, CCing YunQuiang Su.

>> mipsel:
>> 101 failures, see
>> https://buildd.debian.org/status/fetch.php?pkg=binutils&arch=mipsel&ver=2.34.90.20200706-1&stamp=1594122742&raw=1
>
>  This builds natively and therefore I gather these are the usual compiled
> test failures.  As I recall a couple are genuine, such as the IFUNC tests,
> and many are due to ABI mismatches between object files built with GCC and
> ones assembled directly with GAS caused by incompatible code generation
> options, as GAS and/or LD defaults are often different from GCC defaults.  
> The test framework would have to be updated accordingly for these to work.
>
>  HTH,
>
>   Maciej
>

Reply | Threaded
Open this post in threaded view
|

Re: test results with the 2.35 branch for several architectures

Maciej W. Rozycki
On Wed, 22 Jul 2020, Matthias Klose wrote:

> >  Some of the GAS failures are bugs in the respective test cases, which
> > fail to select an ABI with assembly and just happen to work with both o32
> > and n32, but not n64.
>
> Thanks for looking at this, this change was requested by one of the Debian MIPS
> porters, CCing YunQuiang Su.

 Nothing wrong with the change itself; I've had binutils similarly patched
locally for some of my configurations for some 20 years now.  However one
consequence is the Debian test results do not reflect upstream status.

 So you either need to XFAIL the test cases locally, or (preferably, but I
realise that would require more attention) fix the testsuite to handle n64
correctly throughout.

 Submitting such an actual fix upstream will be appreciated, as this issue
also affects our `mips64*-*-openbsd' targets as they stand.  This is not
exactly easy though, especially with the generic tests affected, due to
MIPS/n64's peculiar relocation format.  It should be somewhat easier for
the MIPS-specific tests though with the various test framework portability
updates I have made over the years.

 NB my local patches to make n64 the default for 64-bit Linux do not
adjust the testsuite either; initially I wasn't interested, and then I
never got back to it.  I may yet double-check if I have left anything
behind there.

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: test results with the 2.35 branch for several architectures

YunQiang Su-2
Maciej W. Rozycki <[hidden email]> 于2020年7月22日周三 下午9:25写道:

>
> On Wed, 22 Jul 2020, Matthias Klose wrote:
>
> > >  Some of the GAS failures are bugs in the respective test cases, which
> > > fail to select an ABI with assembly and just happen to work with both o32
> > > and n32, but not n64.
> >
> > Thanks for looking at this, this change was requested by one of the Debian MIPS
> > porters, CCing YunQuiang Su.
>
>  Nothing wrong with the change itself; I've had binutils similarly patched
> locally for some of my configurations for some 20 years now.  However one
> consequence is the Debian test results do not reflect upstream status.
>
>  So you either need to XFAIL the test cases locally, or (preferably, but I
> realise that would require more attention) fix the testsuite to handle n64
> correctly throughout.
>
>  Submitting such an actual fix upstream will be appreciated, as this issue

I figure out a patch several months ago. while I decide to submit
testsuite for r6 first:
do you have interest to have review it?
    https://sourceware.org/bugzilla/show_bug.cgi?id=25494
I will fix the testsuite for N64 then:
   https://sourceware.org/bugzilla/show_bug.cgi?id=25136

> also affects our `mips64*-*-openbsd' targets as they stand.  This is not
> exactly easy though, especially with the generic tests affected, due to
> MIPS/n64's peculiar relocation format.  It should be somewhat easier for
> the MIPS-specific tests though with the various test framework portability
> updates I have made over the years.
>
>  NB my local patches to make n64 the default for 64-bit Linux do not
> adjust the testsuite either; initially I wasn't interested, and then I
> never got back to it.  I may yet double-check if I have left anything
> behind there.
>
>   Maciej
Reply | Threaded
Open this post in threaded view
|

Re: test results with the 2.35 branch for several architectures

Maciej W. Rozycki
On Fri, 24 Jul 2020, YunQiang Su wrote:

> >  So you either need to XFAIL the test cases locally, or (preferably, but I
> > realise that would require more attention) fix the testsuite to handle n64
> > correctly throughout.
> >
> >  Submitting such an actual fix upstream will be appreciated, as this issue
>
> I figure out a patch several months ago. while I decide to submit
> testsuite for r6 first:
> do you have interest to have review it?
>     https://sourceware.org/bugzilla/show_bug.cgi?id=25494
> I will fix the testsuite for N64 then:
>    https://sourceware.org/bugzilla/show_bug.cgi?id=25136

 FTR I have noted my observations with both PRs.  Please let me know if
you have anything to add.

  Maciej