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