public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* buildbot vs --enable-targets=all
@ 2022-07-25 12:25 Mark Wielaard
  2022-07-26  1:24 ` Alan Modra
  2022-07-26  1:59 ` Jeffrey Walton
  0 siblings, 2 replies; 12+ messages in thread
From: Mark Wielaard @ 2022-07-25 12:25 UTC (permalink / raw)
  To: binutils, gdb

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,

Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: buildbot vs --enable-targets=all
  2022-07-25 12:25 buildbot vs --enable-targets=all Mark Wielaard
@ 2022-07-26  1:24 ` Alan Modra
  2022-07-26 11:46   ` Alan Modra
  2022-07-26  1:59 ` Jeffrey Walton
  1 sibling, 1 reply; 12+ messages in thread
From: Alan Modra @ 2022-07-26  1:24 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: binutils, gdb

On Mon, Jul 25, 2022 at 02:25:42PM +0200, Mark Wielaard wrote:
> 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

The line should match the last line of ld-powerpc/tlsexe32.r.  Three
possibilities occur to me that might cause this:
1) There really is a duplicate globel ie0 symbol, or readelf is
   duplicating an output line.
2) expect/dejagnu is duplicating output lines to dump.out, or reading
   that file back when matching regexps duplicates the last line.
3) The last line of tlsexe32.r is dropped from the git checkout, or
   when matching regexps.

None of these things happen elsewhere as far as I know.  ie. the build
bot is broken.

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: buildbot vs --enable-targets=all
  2022-07-25 12:25 buildbot vs --enable-targets=all Mark Wielaard
  2022-07-26  1:24 ` Alan Modra
@ 2022-07-26  1:59 ` Jeffrey Walton
  2022-08-03 10:38   ` Mark Wielaard
  1 sibling, 1 reply; 12+ messages in thread
From: Jeffrey Walton @ 2022-07-26  1:59 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: Binutils, Mahmood Naderan via Gdb

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: buildbot vs --enable-targets=all
  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
  0 siblings, 2 replies; 12+ messages in thread
From: Alan Modra @ 2022-07-26 11:46 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: binutils, gdb

On Tue, Jul 26, 2022 at 10:54:12AM +0930, Alan Modra wrote:
> On Mon, Jul 25, 2022 at 02:25:42PM +0200, Mark Wielaard wrote:
> > 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
> 
> The line should match the last line of ld-powerpc/tlsexe32.r.  Three
> possibilities occur to me that might cause this:
> 1) There really is a duplicate globel ie0 symbol, or readelf is
>    duplicating an output line.
> 2) expect/dejagnu is duplicating output lines to dump.out, or reading
>    that file back when matching regexps duplicates the last line.
> 3) The last line of tlsexe32.r is dropped from the git checkout, or
>    when matching regexps.
> 
> None of these things happen elsewhere as far as I know.  ie. the build
> bot is broken.

Oh, you tricked me.  It's not just a single "extra line in.." but a
bunch of differences then finally that one.

So for some reason there is an empty .data section, putting all the
rest of the dump off by one.

regexp_diff match failure
regexp "^ +\[[ 0-9]+\] \.symtab +SYMTAB +.*$"
line   "  [13] .data             PROGBITS        01810398 000398 000000 00  WA  0   0  1"
regexp_diff match failure
regexp "^ +\[[ 0-9]+\] \.strtab +STRTAB +.*$"
line   "  [14] .symtab           SYMTAB          00000000 000398 000290 10     15  26  4"
regexp_diff match failure


-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: buildbot vs --enable-targets=all
  2022-07-26 11:46   ` Alan Modra
@ 2022-07-26 12:43     ` Alan Modra
  2022-07-26 12:55     ` Mark Wielaard
  1 sibling, 0 replies; 12+ messages in thread
From: Alan Modra @ 2022-07-26 12:43 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: binutils, gdb

On Tue, Jul 26, 2022 at 09:16:50PM +0930, Alan Modra wrote:
> So for some reason there is an empty .data section, putting all the
> rest of the dump off by one.

Reproduced here too.  

.data           0x0000000001810398        0x0
 *crt1.o(.data .data.* .gnu.linkonce.d.*)
                [!provide]                        PROVIDE (__spe_handle = .)
 *(.data.spehandle)
                0x0000000001810398                . = (. + (0x4 * (DEFINED (__spe_handle) || (. != 0x0))))
 *(.data .data.* .gnu.linkonce.d.*)
 .data          0x0000000001810398        0x0 tmpdir/tls32.o

So .data is there due to this configuration dependent snippet in
ld/emulparams/elf32.sh:

if grep -q 'ld_elf32_spu_emulation' ldemul-list.h; then
# crt1.o defines data_start and __data_start.  Keep them first.
# Next put all the .data.spehandle sections, with a trailing zero word.
  DATA_START_SYMBOLS="${RELOCATING+*crt1.o(.data .data.* .gnu.linkonce.d.*)
    PROVIDE (__spe_handle = .);
    *(.data.spehandle)
    . += 4 * (DEFINED (__spe_handle) || . != 0);}"
fi

I'm about to commit the following to silence these benign fails.

	* testsuite/ld-powerpc/tlsexe32.r: Pass with .data section present.
	* testsuite/ld-powerpc/tlsexe32no.r: Likewise.
	* testsuite/ld-powerpc/tlsso32.r: Likewise.

diff --git a/ld/testsuite/ld-powerpc/tlsexe32.r b/ld/testsuite/ld-powerpc/tlsexe32.r
index 43db7379a4c..0e5765911a5 100644
--- a/ld/testsuite/ld-powerpc/tlsexe32.r
+++ b/ld/testsuite/ld-powerpc/tlsexe32.r
@@ -22,9 +22,6 @@ Section Headers:
  +\[[ 0-9]+\] \.dynamic +DYNAMIC +[0-9a-f]+ [0-9a-f]+ [0-9a-f]+ 08 +WA +4 +0 +4
  +\[[ 0-9]+\] \.got +PROGBITS +[0-9a-f]+ [0-9a-f]+ 000018 04 +WA +0 +0 +4
  +\[[ 0-9]+\] \.plt +PROGBITS +[0-9a-f]+ [0-9a-f]+ 000004 00 +WA +0 +0 +4
- +\[[ 0-9]+\] \.symtab +SYMTAB +.*
- +\[[ 0-9]+\] \.strtab +STRTAB +.*
- +\[[ 0-9]+\] \.shstrtab +STRTAB +.*
 #...
 
 Elf file type is EXEC \(Executable file\)
@@ -81,6 +78,7 @@ Symbol table '\.symtab' contains [0-9]+ entries:
 .* SECTION +LOCAL +DEFAULT +10 \.dynamic
 .* SECTION +LOCAL +DEFAULT +11 \.got
 .* SECTION +LOCAL +DEFAULT +12 \.plt
+#...
 .* FILE +LOCAL +DEFAULT +ABS .*
 .* NOTYPE +LOCAL +DEFAULT +ABS TLSMARK
 .* TLS +LOCAL +DEFAULT +8 gd4
@@ -99,12 +97,12 @@ Symbol table '\.symtab' contains [0-9]+ entries:
 .* TLS +GLOBAL +DEFAULT +9 le1
 .* TLS +GLOBAL +DEFAULT +UND ld
 .* NOTYPE +GLOBAL +DEFAULT +7 _start
-.* NOTYPE +GLOBAL +DEFAULT +12 __end
+.* NOTYPE +GLOBAL +DEFAULT +1[23] __end
 .* TLS +GLOBAL +DEFAULT +9 ld2
 .* TLS +GLOBAL +DEFAULT +9 ld1
-.* NOTYPE +GLOBAL +DEFAULT +12 __bss_start
+.* NOTYPE +GLOBAL +DEFAULT +1[23] __bss_start
 .* FUNC +GLOBAL +DEFAULT +UND __tls_get_addr_opt
-.* NOTYPE +GLOBAL +DEFAULT +12 _edata
-.* NOTYPE +GLOBAL +DEFAULT +12 _end
+.* NOTYPE +GLOBAL +DEFAULT +1[23] _edata
+.* NOTYPE +GLOBAL +DEFAULT +1[23] _end
 .* TLS +GLOBAL +DEFAULT +9 gd0
 .* TLS +GLOBAL +DEFAULT +9 ie0
diff --git a/ld/testsuite/ld-powerpc/tlsexe32no.r b/ld/testsuite/ld-powerpc/tlsexe32no.r
index e254eeadf71..a9fb4373a96 100644
--- a/ld/testsuite/ld-powerpc/tlsexe32no.r
+++ b/ld/testsuite/ld-powerpc/tlsexe32no.r
@@ -22,9 +22,6 @@ Section Headers:
  +\[[ 0-9]+\] \.dynamic +DYNAMIC +[0-9a-f]+ [0-9a-f]+ [0-9a-f]+ 08 +WA +4 +0 +4
  +\[[ 0-9]+\] \.got +PROGBITS +[0-9a-f]+ [0-9a-f]+ 000038 04 +WA +0 +0 +4
  +\[[ 0-9]+\] \.plt +PROGBITS +[0-9a-f]+ [0-9a-f]+ 000004 00 +WA +0 +0 +4
- +\[[ 0-9]+\] \.symtab +SYMTAB +.*
- +\[[ 0-9]+\] \.strtab +STRTAB +.*
- +\[[ 0-9]+\] \.shstrtab +STRTAB +.*
 #...
 
 Elf file type is EXEC \(Executable file\)
@@ -82,6 +79,7 @@ Symbol table '\.symtab' contains [0-9]+ entries:
 .* SECTION +LOCAL +DEFAULT +10 \.dynamic
 .* SECTION +LOCAL +DEFAULT +11 \.got
 .* SECTION +LOCAL +DEFAULT +12 \.plt
+#...
 .* FILE +LOCAL +DEFAULT +ABS .*
 .* NOTYPE +LOCAL +DEFAULT +ABS TLSMARK
 .* TLS +LOCAL +DEFAULT +8 gd4
@@ -100,12 +98,12 @@ Symbol table '\.symtab' contains [0-9]+ entries:
 .* TLS +GLOBAL +DEFAULT +9 le1
 .* TLS +GLOBAL +DEFAULT +UND ld
 .* NOTYPE +GLOBAL +DEFAULT +7 _start
-.* NOTYPE +GLOBAL +DEFAULT +12 __end
+.* NOTYPE +GLOBAL +DEFAULT +1[23] __end
 .* TLS +GLOBAL +DEFAULT +9 ld2
 .* TLS +GLOBAL +DEFAULT +9 ld1
-.* NOTYPE +GLOBAL +DEFAULT +12 __bss_start
+.* NOTYPE +GLOBAL +DEFAULT +1[23] __bss_start
 .* FUNC +GLOBAL +DEFAULT +UND __tls_get_addr_opt
-.* NOTYPE +GLOBAL +DEFAULT +12 _edata
-.* NOTYPE +GLOBAL +DEFAULT +12 _end
+.* NOTYPE +GLOBAL +DEFAULT +1[23] _edata
+.* NOTYPE +GLOBAL +DEFAULT +1[23] _end
 .* TLS +GLOBAL +DEFAULT +9 gd0
 .* TLS +GLOBAL +DEFAULT +9 ie0
diff --git a/ld/testsuite/ld-powerpc/tlsso32.r b/ld/testsuite/ld-powerpc/tlsso32.r
index 3f92f8066cf..cd4b5e8c2eb 100644
--- a/ld/testsuite/ld-powerpc/tlsso32.r
+++ b/ld/testsuite/ld-powerpc/tlsso32.r
@@ -20,9 +20,6 @@ Section Headers:
  +\[[ 0-9]+\] \.dynamic +DYNAMIC .* 08 +WA +3 +0 +4
  +\[[ 0-9]+\] \.got +PROGBITS .* 0+40 04 +WA +0 +0 +4
  +\[[ 0-9]+\] \.plt +PROGBITS .* 0+4 00 +WA +0 +0 +4
- +\[[ 0-9]+\] \.symtab +.*
- +\[[ 0-9]+\] \.strtab +.*
- +\[[ 0-9]+\] \.shstrtab +.*
 #...
 
 Elf file type is DYN \(Shared object file\)
@@ -100,6 +97,7 @@ Symbol table '\.symtab' contains [0-9]+ entries:
 .* SECTION +LOCAL +DEFAULT +9 \.dynamic
 .* SECTION +LOCAL +DEFAULT +10 \.got
 .* SECTION +LOCAL +DEFAULT +11 \.plt
+#...
 .* FILE +LOCAL +DEFAULT +ABS .*
 .* NOTYPE +LOCAL +DEFAULT +ABS TLSMARK
 .* TLS +LOCAL +DEFAULT +7 gd4


-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: buildbot vs --enable-targets=all
  2022-07-26 11:46   ` Alan Modra
  2022-07-26 12:43     ` Alan Modra
@ 2022-07-26 12:55     ` Mark Wielaard
  1 sibling, 0 replies; 12+ messages in thread
From: Mark Wielaard @ 2022-07-26 12:55 UTC (permalink / raw)
  To: Alan Modra; +Cc: binutils, gdb

Hi Alan,

On Tue, 2022-07-26 at 21:16 +0930, Alan Modra wrote:
> On Tue, Jul 26, 2022 at 10:54:12AM +0930, Alan Modra wrote:
> > On Mon, Jul 25, 2022 at 02:25:42PM +0200, Mark Wielaard wrote:
> > > 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
> > [...]
> Oh, you tricked me.  It's not just a single "extra line in.." but a
> bunch of differences then finally that one.

Apologies, I didn't mean to deceive. Just copy/pasted not enough
context.

The full logs files can be found in the bunsendb (see the upload bunsen
step):
https://builder.sourceware.org/testrun/b2ea62b46f245693bf32bdfdabedf95cdc31bd4f

The webwidget has a dejagnu parse view:
https://builder.sourceware.org/testrun/b2ea62b46f245693bf32bdfdabedf95cdc31bd4f?focus=dgsummary

Which you can then use to get at the specific part of the .log file for
an .exp per test:
https://builder.sourceware.org/testrun/b2ea62b46f245693bf32bdfdabedf95cdc31bd4f?dgexpfile=ld-powerpc%2Fpowerpc.exp

In this case:
https://builder.sourceware.org/testrun/b2ea62b46f245693bf32bdfdabedf95cdc31bd4f?filename=ld%2Fld.log&fileline=53358&linewindow=20#line53358

> So for some reason there is an empty .data section, putting all the
> rest of the dump off by one.
> 
> regexp_diff match failure
> regexp "^ +\[[ 0-9]+\] \.symtab +SYMTAB +.*$"
> line   "  [13] .data             PROGBITS        01810398 000398
> 000000 00  WA  0   0  1"
> regexp_diff match failure
> regexp "^ +\[[ 0-9]+\] \.strtab +STRTAB +.*$"
> line   "  [14] .symtab           SYMTAB          00000000 000398
> 000290 10     15  26  4"
> regexp_diff match failure

Thanks. I don't know where that is coming from. It is curious that it
happens on both debian-ppc64 and fedora-ppc64le which are somewhat
different environments.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: buildbot vs --enable-targets=all
  2022-07-26  1:59 ` Jeffrey Walton
@ 2022-08-03 10:38   ` Mark Wielaard
  2022-08-03 10:56     ` Andreas Schwab
  2022-08-03 11:35     ` Luis Machado
  0 siblings, 2 replies; 12+ messages in thread
From: Mark Wielaard @ 2022-08-03 10:38 UTC (permalink / raw)
  To: noloader; +Cc: Binutils, Gdb

Hi Jeffrey,

On Mon, 2022-07-25 at 21:59 -0400, Jeffrey Walton wrote:
> On Mon, Jul 25, 2022 at 8:26 AM Mark Wielaard <mark@klomp.org> wrote:
> > 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.
> [...]

> > 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.

I couldn't figure out how to do that. Could you give an example?
It looks like the instruction_reader_thumb only takes an array of
uint16_t (even though the instructions are 32bit long). But I might be
looking at the wrong code.

So the following fixes it for me on s390x and ppc64

diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index d4c5beb5e06..ef0da73398d 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -14471,7 +14471,7 @@ arm_record_test (void)
 
     static const uint16_t insns[] = {
       /* 1d ee 70 7f    mrc    15, 0, r7, cr13, cr0, {3} */
-      0xee1d, 0x7f70,
+      0x7f70, 0xee1d,
     };
 
     enum bfd_endian endian = gdbarch_byte_order_for_code (arm_record.gdbarch);

But obviously that breaks things on little-endian architectures.
We could define the insns[] differently using

 #if _BYTE_ORDER == _LITTLE_ENDIAN
      0xee1d, 0x7f70,
 #else
      0x7f70, 0xee1d,
 #endif

But that might not be what you meant.

Thanks,

Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: buildbot vs --enable-targets=all
  2022-08-03 10:38   ` Mark Wielaard
@ 2022-08-03 10:56     ` Andreas Schwab
  2022-08-03 11:35     ` Luis Machado
  1 sibling, 0 replies; 12+ messages in thread
From: Andreas Schwab @ 2022-08-03 10:56 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: noloader, Gdb, Binutils

On Aug 03 2022, Mark Wielaard wrote:

> It looks like the instruction_reader_thumb only takes an array of
> uint16_t (even though the instructions are 32bit long). But I might be
> looking at the wrong code.

I think the right place to fix that is in
instruction_reader_thumb::read, when len == 4.  Or perhaps there should
be a class instruction_reader_thumb2 that uses uint32_t instead of
uint16_t.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: buildbot vs --enable-targets=all
  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
  1 sibling, 1 reply; 12+ messages in thread
From: Luis Machado @ 2022-08-03 11:35 UTC (permalink / raw)
  To: Mark Wielaard, noloader; +Cc: Gdb, Binutils

On 8/3/22 11:38, Mark Wielaard wrote:
> Hi Jeffrey,
> 
> On Mon, 2022-07-25 at 21:59 -0400, Jeffrey Walton wrote:
>> On Mon, Jul 25, 2022 at 8:26 AM Mark Wielaard <mark@klomp.org> wrote:
>>> 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.
>> [...]
> 
>>> 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.
> 
> I couldn't figure out how to do that. Could you give an example?
> It looks like the instruction_reader_thumb only takes an array of
> uint16_t (even though the instructions are 32bit long). But I might be
> looking at the wrong code.
> 
> So the following fixes it for me on s390x and ppc64
> 
> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
> index d4c5beb5e06..ef0da73398d 100644
> --- a/gdb/arm-tdep.c
> +++ b/gdb/arm-tdep.c
> @@ -14471,7 +14471,7 @@ arm_record_test (void)
>   
>       static const uint16_t insns[] = {
>         /* 1d ee 70 7f    mrc    15, 0, r7, cr13, cr0, {3} */
> -      0xee1d, 0x7f70,
> +      0x7f70, 0xee1d,
>       };
>   
>       enum bfd_endian endian = gdbarch_byte_order_for_code (arm_record.gdbarch);
> 
> But obviously that breaks things on little-endian architectures.
> We could define the insns[] differently using
> 
>   #if _BYTE_ORDER == _LITTLE_ENDIAN
>        0xee1d, 0x7f70,
>   #else
>        0x7f70, 0xee1d,
>   #endif
> 
> But that might not be what you meant.
> 
> Thanks,
> 
> Mark

I wonder what's going wrong here given we're using gdbarch_byte_order_for_code to read things.

Technically it should read in the right order.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: buildbot vs --enable-targets=all
  2022-08-03 11:35     ` Luis Machado
@ 2022-08-03 11:49       ` Mark Wielaard
  2022-08-03 11:54         ` Luis Machado
  0 siblings, 1 reply; 12+ messages in thread
From: Mark Wielaard @ 2022-08-03 11:49 UTC (permalink / raw)
  To: Luis Machado, noloader; +Cc: Gdb, Binutils

Hi Luis,

On Wed, 2022-08-03 at 12:35 +0100, Luis Machado wrote:
> On 8/3/22 11:38, Mark Wielaard wrote:
> > On Mon, 2022-07-25 at 21:59 -0400, Jeffrey Walton wrote:
> > > On Mon, Jul 25, 2022 at 8:26 AM Mark Wielaard <mark@klomp.org>
> > > wrote:
> > > > 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.
> > > 
> > > [...]
> > > > 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.
> > 
> > I couldn't figure out how to do that. Could you give an example?
> > It looks like the instruction_reader_thumb only takes an array of
> > uint16_t (even though the instructions are 32bit long). But I might
> > be
> > looking at the wrong code.
> > 
> > So the following fixes it for me on s390x and ppc64
> > 
> > diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
> > index d4c5beb5e06..ef0da73398d 100644
> > --- a/gdb/arm-tdep.c
> > +++ b/gdb/arm-tdep.c
> > @@ -14471,7 +14471,7 @@ arm_record_test (void)
> >   
> >       static const uint16_t insns[] = {
> >         /* 1d ee 70 7f    mrc    15, 0, r7, cr13, cr0, {3} */
> > -      0xee1d, 0x7f70,
> > +      0x7f70, 0xee1d,
> >       };
> >   
> >       enum bfd_endian endian = gdbarch_byte_order_for_code
> > (arm_record.gdbarch);
> > 
> > But obviously that breaks things on little-endian architectures.
> > We could define the insns[] differently using
> > 
> >   #if _BYTE_ORDER == _LITTLE_ENDIAN
> >        0xee1d, 0x7f70,
> >   #else
> >        0x7f70, 0xee1d,
> >   #endif
> > 
> > But that might not be what you meant.
> > 
> I wonder what's going wrong here given we're using
> gdbarch_byte_order_for_code to read things.
> 
> Technically it should read in the right order.

Yes, if the code bytes were in the right order. Like when you read them
from disk or from a process running in that byte order. But here they
are constructed in memory in the byte order of the host architecture as
an uint16_t array. So when using the gdbarch_byte_order_for_code order
to reconstruct those instructions it is not using the host byte order
(if they don't match).

I think what Jeffrey means is that there is a different way to
construct the bytes in memory using .inst.n and .inst.w, but I don't
fully understand how that works.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: buildbot vs --enable-targets=all
  2022-08-03 11:49       ` Mark Wielaard
@ 2022-08-03 11:54         ` Luis Machado
  2022-08-03 11:57           ` Mark Wielaard
  0 siblings, 1 reply; 12+ messages in thread
From: Luis Machado @ 2022-08-03 11:54 UTC (permalink / raw)
  To: Mark Wielaard, noloader; +Cc: Gdb, Binutils

On 8/3/22 12:49, Mark Wielaard wrote:
> Hi Luis,
> 
> On Wed, 2022-08-03 at 12:35 +0100, Luis Machado wrote:
>> On 8/3/22 11:38, Mark Wielaard wrote:
>>> On Mon, 2022-07-25 at 21:59 -0400, Jeffrey Walton wrote:
>>>> On Mon, Jul 25, 2022 at 8:26 AM Mark Wielaard <mark@klomp.org>
>>>> wrote:
>>>>> 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.
>>>>
>>>> [...]
>>>>> 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.
>>>
>>> I couldn't figure out how to do that. Could you give an example?
>>> It looks like the instruction_reader_thumb only takes an array of
>>> uint16_t (even though the instructions are 32bit long). But I might
>>> be
>>> looking at the wrong code.
>>>
>>> So the following fixes it for me on s390x and ppc64
>>>
>>> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
>>> index d4c5beb5e06..ef0da73398d 100644
>>> --- a/gdb/arm-tdep.c
>>> +++ b/gdb/arm-tdep.c
>>> @@ -14471,7 +14471,7 @@ arm_record_test (void)
>>>    
>>>        static const uint16_t insns[] = {
>>>          /* 1d ee 70 7f    mrc    15, 0, r7, cr13, cr0, {3} */
>>> -      0xee1d, 0x7f70,
>>> +      0x7f70, 0xee1d,
>>>        };
>>>    
>>>        enum bfd_endian endian = gdbarch_byte_order_for_code
>>> (arm_record.gdbarch);
>>>
>>> But obviously that breaks things on little-endian architectures.
>>> We could define the insns[] differently using
>>>
>>>    #if _BYTE_ORDER == _LITTLE_ENDIAN
>>>         0xee1d, 0x7f70,
>>>    #else
>>>         0x7f70, 0xee1d,
>>>    #endif
>>>
>>> But that might not be what you meant.
>>>
>> I wonder what's going wrong here given we're using
>> gdbarch_byte_order_for_code to read things.
>>
>> Technically it should read in the right order.
> 
> Yes, if the code bytes were in the right order. Like when you read them
> from disk or from a process running in that byte order. But here they
> are constructed in memory in the byte order of the host architecture as
> an uint16_t array. So when using the gdbarch_byte_order_for_code order
> to reconstruct those instructions it is not using the host byte order
> (if they don't match).
> 
> I think what Jeffrey means is that there is a different way to
> construct the bytes in memory using .inst.n and .inst.w, but I don't
> fully understand how that works.
> 
> Cheers,
> 
> Mark

Ah, I see. And s390/ppc being potentially big endian, this fails.

I managed to reproduce this on my end by forcing GDB to use big endian. Could you please file a PR for this one and cc me?

I'll try to come up with a fix.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: buildbot vs --enable-targets=all
  2022-08-03 11:54         ` Luis Machado
@ 2022-08-03 11:57           ` Mark Wielaard
  0 siblings, 0 replies; 12+ messages in thread
From: Mark Wielaard @ 2022-08-03 11:57 UTC (permalink / raw)
  To: Luis Machado, noloader; +Cc: Gdb, Binutils

Hi Luis,

On Wed, 2022-08-03 at 12:54 +0100, Luis Machado wrote:
> Ah, I see. And s390/ppc being potentially big endian, this fails.
> 
> I managed to reproduce this on my end by forcing GDB to use big
> endian. Could you please file a PR for this one and cc me?
> 
> I'll try to come up with a fix.

https://sourceware.org/bugzilla/show_bug.cgi?id=29432

Thanks,

Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2022-08-03 11:57 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-25 12:25 buildbot vs --enable-targets=all 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
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

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).