public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Jeffrey Walton <noloader@gmail.com>
To: Mark Wielaard <mark@klomp.org>
Cc: Binutils <binutils@sourceware.org>,
	Mahmood Naderan via Gdb <gdb@sourceware.org>
Subject: Re: buildbot vs --enable-targets=all
Date: Mon, 25 Jul 2022 21:59:25 -0400	[thread overview]
Message-ID: <CAH8yC8nD9JQPnRBKrxxKZJsq1OmEyj3duLDp1axG3qh70nrefw@mail.gmail.com> (raw)
In-Reply-To: <94d446556e470859b878bb27eec5e2a52d063673.camel@klomp.org>

On Mon, Jul 25, 2022 at 8:26 AM Mark Wielaard <mark@klomp.org> 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

  parent reply	other threads:[~2022-07-26  2:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-25 12:25 Mark Wielaard
2022-07-26  1:24 ` Alan Modra
2022-07-26 11:46   ` Alan Modra
2022-07-26 12:43     ` Alan Modra
2022-07-26 12:55     ` Mark Wielaard
2022-07-26  1:59 ` Jeffrey Walton [this message]
2022-08-03 10:38   ` Mark Wielaard
2022-08-03 10:56     ` Andreas Schwab
2022-08-03 11:35     ` Luis Machado
2022-08-03 11:49       ` Mark Wielaard
2022-08-03 11:54         ` Luis Machado
2022-08-03 11:57           ` Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH8yC8nD9JQPnRBKrxxKZJsq1OmEyj3duLDp1axG3qh70nrefw@mail.gmail.com \
    --to=noloader@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=gdb@sourceware.org \
    --cc=mark@klomp.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).