Re: buildbot vs --enable-targets=all

Jeffrey Walton via Gdb <[email protected]>
Newsgroups gmane.comp.gdb.devel,gmane.comp.gnu.binutils
Message-ID <CAH8yC8nD9JQPnRBKrxxKZJsq1OmEyj3duLDp1axG3qh70nrefw@mail.gmail.com>
On Mon, Jul 25, 2022 at 8:26 AM Mark Wielaard <[email protected]> wrote:
>
> Hi,
>
> I enabled --enable-targets=all for all builds on builder.sourceware.org
> (with --disable-sim for 32bit gdb builds), which exposed some new
> failing tests. I can disable --enable-targets=all again, but maybe it
> makes sense to look at the failures and try to fix them.
>
> On fedora-s390x and debian-ppc64 one of the gdb selftests fails
> https://builder.sourceware.org/buildbot/#builders/75/builds/783
> https://builder.sourceware.org/buildbot/#builders/76/builds/772
>
> Running selftest arm-record.
> Process record and replay target doesn't support syscall number
> -2036195
> Process record does not support instruction 0x7f70ee1d at address 0x0.
> Self test failed: self-test failed at ../../binutils-gdb/gdb/arm-
> tdep.c:14407
>
> Which is:
>
>   /* 32-bit Thumb-2 instructions.  */
>   {
>     arm_insn_decode_record arm_record;
>
>     memset (&arm_record, 0, sizeof (arm_insn_decode_record));
>     arm_record.gdbarch = gdbarch;
>
>     static const uint16_t insns[] = {
>       /* 1d ee 70 7f     mrc    15, 0, r7, cr13, cr0, {3} */
>       0xee1d, 0x7f70,
>     };
>
>     enum bfd_endian endian = gdbarch_byte_order_for_code (arm_record.gdbarch);
>     instruction_reader_thumb reader (endian, insns);
>     int ret = decode_insn (reader, &arm_record, THUMB2_RECORD,
>                            THUMB2_INSN_SIZE_BYTES);
>
>     SELF_CHECK (ret == 0);
>     SELF_CHECK (arm_record.mem_rec_count == 0);
>     SELF_CHECK (arm_record.reg_rec_count == 1);
>     SELF_CHECK (arm_record.arm_regs[0] == 7);
>   }
>
> This seems a big endian issue given the instructions are given as two
> 16bit numbers.
>
> On debian-ppc64 and fedora-ppc64le there are the following ld failures:
> https://builder.sourceware.org/buildbot/#builders/86/builds/343
> https://builder.sourceware.org/buildbot/#builders/78/builds/382
>
> extra lines in dump.out starting with "^    40: 0000002c     0
> TLS     GLOBAL DEFAULT    9 ie0$"
> EOF from /var/lib/buildbot/workers/wildebeest/binutils-debian-
> ppc64/binutils-gdb/ld/testsuite/ld-powerpc/tlsexe32.r
> FAIL: TLS32 dynamic exec
>
> extra lines in dump.out starting with "^    40: 0000002c     0
> TLS     GLOBAL DEFAULT    9 ie0$"
> EOF from /var/lib/buildbot/workers/wildebeest/binutils-debian-
> ppc64/binutils-gdb/ld/testsuite/ld-powerpc/tlsexe32no.r
> FAIL: TLS32 dynamic exec (--no-tls-optimize)
>
> extra lines in dump.out starting with "^    38: 0000002c     0
> TLS     GLOBAL DEFAULT    8 ie0$"
> EOF from /var/lib/buildbot/workers/wildebeest/binutils-debian-
> ppc64/binutils-gdb/ld/testsuite/ld-powerpc/tlsso32.r
> FAIL: TLS32 shared
>
> On debian-armhf there are the following gas failures:
> https://builder.sourceware.org/buildbot/#builders/80/builds/350
>
> ../as-new  -mcpu=cortex-a76ae  -o tmpdir/nop-asm.o
> /var/lib/buildbot/workers/wildebeest/binutils-debian-armhf/binutils-
> gdb/gas/testsuite/gas/arm/nop-asm.s
> Executing on host: sh -c
> {/var/lib/buildbot/workers/wildebeest/binutils-debian-armhf/binutils-
> build/gas/testsuite/../../binutils/objdump  -d -mcortex-a76ae
> tmpdir/nop-asm.o > tmpdir/dump.out 2>dump.tmp}  /dev/null  (timeout =
> 300)
> spawn [open ...]
> exited abnormally with 1,
> output:/var/lib/buildbot/workers/wildebeest/binutils-debian-
> armhf/binutils-build/binutils/.libs/objdump: can't disassemble for
> architecture aarch64
>
> FAIL: Assemble and dump for cortex-a76ae CPU
>
> ../as-new  -mcpu=cortex-a77  -o tmpdir/nop-asm.o
> /var/lib/buildbot/workers/wildebeest/binutils-debian-armhf/binutils-
> gdb/gas/testsuite/gas/arm/nop-asm.s
> Executing on host: sh -c {../as-new  -mcpu=cortex-a77  -o tmpdir/nop-
> asm.o /var/lib/buildbot/workers/wildebeest/binutils-debian-
> armhf/binutils-gdb/gas/testsuite/gas/arm/nop-asm.s 2>&1}  /dev/null
> dump.tmp (timeout = 300)
> spawn [open ...]
> /var/lib/buildbot/workers/wildebeest/binutils-debian-armhf/binutils-
> build/gas/testsuite/../../binutils/objdump  -d -mcortex-a77 tmpdir/nop-
> asm.o > tmpdir/dump.out
> Executing on host: sh -c
> {/var/lib/buildbot/workers/wildebeest/binutils-debian-armhf/binutils-
> build/gas/testsuite/../../binutils/objdump  -d -mcortex-a77 tmpdir/nop-
> asm.o > tmpdir/dump.out 2>dump.tmp}  /dev/null  (timeout = 300)
> spawn [open ...]
> exited abnormally with 1,
> output:/var/lib/buildbot/workers/wildebeest/binutils-debian-
> armhf/binutils-build/binutils/.libs/objdump: can't disassemble for
> architecture aarch64
>
> FAIL: Assemble and dump for cortex-a77 CPU
>
> On fedora-arm64 there is one unexpected failure and pass:
> https://builder.sourceware.org/buildbot/#builders/176/builds/37
>
>
> tmpdir/pr26094-1c.o: in function `foo':
> /home/builder/worker/binutils-fedora-arm64/binutils-
> gdb/ld/testsuite/ld-elf/pr26094-1c.c:7:(.text+0x4): relocation
> truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol
> `__start_FOO@@SOME_VERSION_NAME' defined in FOO section in
> tmpdir/pr26094-1
> /home/builder/worker/binutils-fedora-arm64/binutils-build/ld/.libs/ld-
> new: /home/builder/worker/binutils-fedora-arm64/binutils-
> gdb/ld/testsuite/ld-elf/pr26094-1c.c:7: warning: one possible cause of
> this error is that the symbol is being referenced in the indicated code
> as if it had a larger alignment than was declared where it was defined
> collect2: error: ld returned 1 exit status
> tmpdir/pr26094-1c.o: in function `foo':
> /home/builder/worker/binutils-fedora-arm64/binutils-
> gdb/ld/testsuite/ld-elf/pr26094-1c.c:7:(.text+0x4): relocation
> truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol
> `__start_FOO@@SOME_VERSION_NAME' defined in FOO section in
> tmpdir/pr26094-1
> /home/builder/worker/binutils-fedora-arm64/binutils-build/ld/.libs/ld-
> new: /home/builder/worker/binutils-fedora-arm64/binutils-
> gdb/ld/testsuite/ld-elf/pr26094-1c.c:7: warning: one possible cause of
> this error is that the symbol is being referenced in the indicated code
> as if it had a larger alignment than was declared where it was defined
> collect2: error: ld returned 1 exit status
> Unexpected linker warning or error
> FAIL: Build pr26094-1
>
> cp tmpdir/libpr19719a.so tmpdir/libpr19719.so
> tmpdir/pr19719
> Executing on host: sh -c {tmpdir/pr19719   2>&1}  /dev/null ld.tmp
> (timeout = 300)
> spawn [open ...]
> PASS
> PASS
> XPASS: Run pr19719 fun undefined
>
> Cheers,

For ARM, this does not look right (to me):

>     static const uint16_t insns[] = {
>       /* 1d ee 70 7f     mrc    15, 0, r7, cr13, cr0, {3} */
>       0xee1d, 0x7f70,
>     };

I think you are supposed to use .inst.n and .inst.w because they
handle endianness properly.

Jeff
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.