Simon Marchi [Tue, 19 Oct 2021 19:32:08 +0000 (15:32 -0400)]
gdbsupport: add assertions in array_view
Add assertions to ensure we don't access an array_view out of bounds.
Enable these assertions only when _GLIBCXX_DEBUG is set, as we did for
gdb::optional.
Change-Id: Iffaee38252405073735ed123c8e57fde6b2c6be3
Simon Marchi [Mon, 25 Oct 2021 18:33:55 +0000 (14:33 -0400)]
gdbserver: make target_pid_to_str return std::string
I wanted to write a warning that included two target_pid_to_str calls,
like this:
warning (_("Blabla %s, blabla %s"),
target_pid_to_str (ptid1),
target_pid_to_str (ptid2));
This doesn't work, because target_pid_to_str stores its result in a
static buffer, so my message would show twice the same ptid. Change
target_pid_to_str to return an std::string to avoid this. I don't think
we save much by using a static buffer, but it is more error-prone.
Change-Id: Ie3f649627686b84930529cc5c7c691ccf5d36dc2
H.J. Lu [Sat, 23 Oct 2021 14:37:33 +0000 (07:37 -0700)]
x86: Also handle stores for -muse-unaligned-vector-move
* config/tc-i386.c (encode_with_unaligned_vector_move): Also
handle stores.
* testsuite/gas/i386/unaligned-vector-move.s: Add stores.
* testsuite/gas/i386/unaligned-vector-move.d: Updated.
* testsuite/gas/i386/x86-64-unaligned-vector-move.d: Likewise.
Tom de Vries [Mon, 25 Oct 2021 16:15:15 +0000 (18:15 +0200)]
[gdb/testsuite] Fix duplicate in gdb.mi/mi-var-cp.exp
With test-case gdb.mi/mi-var-cp.exp I run into this duplicate:
...
PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:104 (set breakpoint)
PASS: gdb.mi/mi-var-cp.exp: create varobj for s
PASS: gdb.mi/mi-var-cp.exp: create varobj for s
DUPLICATE: gdb.mi/mi-var-cp.exp: create varobj for s
...
This is due to a duplicate test name here:
...
$ cat -n gdb/testsuite/gdb.mi/mi-var-cp.cc
...
100 int reference_to_struct ()
101 {
102 /*: BEGIN: reference_to_struct :*/
103 S s = {7, 8};
104 S& r = s;
105 /*:
106 mi_create_varobj S s "create varobj for s"
107 mi_create_varobj R r "create varobj for s"
...
Fix this by using "create varobj for r" instead.
Tested on x86_64-linux.
Nick Alcock [Mon, 25 Oct 2021 10:17:02 +0000 (11:17 +0100)]
libctf, ld: handle nonrepresentable types better
ctf_type_visit (used, among other things, by the type dumping code) was
aborting when it saw a nonrepresentable type anywhere: even a single
structure member with a nonrepresentable type caused an abort with
ECTF_NONREPRESENTABLE. This is not useful behaviour, given that the
abort comes from a type-resolution we are only doing in order to
determine whether the type is a structure or union. We know
nonrepresentable types can't be either, so handle that case and
pass the nonrepresentable type down.
(The added test verifies that the dumper now handles this case and
prints nonrepresentable structure members as it already does
nonrepresentable top-level types, rather than skipping the whole
structure -- or, without the previous commit, skipping the whole types
section.)
ld/ChangeLog
2021-10-25 Nick Alcock <nick.alcock@oracle.com>
* testsuite/ld-ctf/nonrepresentable-member.*: New test.
libctf/ChangeLog
2021-10-25 Nick Alcock <nick.alcock@oracle.com>
* ctf-types.c (ctf_type_rvisit): Handle nonrepresentable types.
Nick Alcock [Mon, 25 Oct 2021 10:17:02 +0000 (11:17 +0100)]
libctf: dump: do not stop dumping types on error
If dumping of a single type fails, we obviously can't dump it; but just
as obviously this doesn't make the other types in the types section
invalid or undumpable. So we should not propagate errors seen when
type-dumping, but rather ignore them and carry on, so we dump as many
types as we can (leaving out the ones we can't grok).
libctf/ChangeLog
2021-10-25 Nick Alcock <nick.alcock@oracle.com>
* ctf-dump.c (ctf_dump_type): Do not abort on error.
Nick Alcock [Mon, 25 Oct 2021 10:17:02 +0000 (11:17 +0100)]
binutils, ld: make objdump --ctf's parameter optional
ld by default (and always, unless adjusted with a hand-rolled linker
script) emits deduplicated CTF into the .ctf section. But viewing
it needs you to explicitly tell objdump this: it doesn't default
its argument, even though what you always end up typing is
--ctf=.ctf.
This is annoying, so make the argument optional.
binutils/ChangeLog
2021-10-25 Nick Alcock <nick.alcock@oracle.com>
* objdump.c (usage): --ctf now has an optional argument.
(main): Adjust accordingly.
(dump_ctf): Default it.
* doc/ctf.options.texi: Adjust.
ld/ChangeLog
2021-10-25 Nick Alcock <nick.alcock@oracle.com>
* testsuite/ld-ctf/array.d: Change --ctf=.ctf to --ctf.
* testsuite/ld-ctf/conflicting-cycle-1.B-1.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-1.B-2.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-1.parent.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-2.A-1.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-2.A-2.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-2.parent.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-3.C-1.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-3.C-2.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-3.parent.d: Likewise.
* testsuite/ld-ctf/conflicting-enums.d: Likewise.
* testsuite/ld-ctf/conflicting-typedefs.d: Likewise.
* testsuite/ld-ctf/cross-tu-cyclic-conflicting.d: Likewise.
* testsuite/ld-ctf/cross-tu-cyclic-nonconflicting.d: Likewise.
* testsuite/ld-ctf/cross-tu-into-cycle.d: Likewise.
* testsuite/ld-ctf/cross-tu-noncyclic.d: Likewise.
* testsuite/ld-ctf/cycle-1.d: Likewise.
* testsuite/ld-ctf/cycle-2.A.d: Likewise.
* testsuite/ld-ctf/cycle-2.B.d: Likewise.
* testsuite/ld-ctf/cycle-2.C.d: Likewise.
* testsuite/ld-ctf/data-func-conflicted.d: Likewise.
* testsuite/ld-ctf/diag-cttname-null.d: Likewise.
* testsuite/ld-ctf/diag-cuname.d: Likewise.
* testsuite/ld-ctf/diag-parlabel.d: Likewise.
* testsuite/ld-ctf/enum-forward.d: Likewise.
* testsuite/ld-ctf/enums.d: Likewise.
* testsuite/ld-ctf/forward.d: Likewise.
* testsuite/ld-ctf/function.d: Likewise.
* testsuite/ld-ctf/nonrepresentable.d: Likewise.
* testsuite/ld-ctf/slice.d: Likewise.
* testsuite/ld-ctf/super-sub-cycles.d: Likewise.
Nick Alcock [Mon, 25 Oct 2021 10:17:02 +0000 (11:17 +0100)]
binutils: make objdump/readelf --ctf-parent actually useful
This option has been present since the very early days of the
development of libctf as part of binutils, and it shows. Back in the
earliest days, I thought we might handle ambiguous types by introducing
new ELF sections on the fly named things like .ctf.foo.c for ambiguous
types found only in foo.c, etc. This turned out to be a terrible idea,
so we moved to using a CTF archive in the .ctf section which contained
all the CTF dictionaries -- but the --ctf-parent option in objdump and
readelf was never adjusted, and lingered as a mechanism to specify CTF
parent dictionaries in sections other than .ctf, even though the linker
has no way to produce parent dictionaries in different sections from
their children, libctf's ctf_open can't handle such split-up
parent/child dicts, and they are never found in the wild, emitted by GNU
ld or by any known third-party linking tool.
Meanwhile, the actually-useful ctf_link feature (albeit not used by ld)
which lets you remap the names of CTF archive members (so you can end up
with a parent archive member named something other than ".ctf", still
contained with all its children in a single .ctf section) had no support
in objdump or readelf: there was no way to tell them that these members
were parents, so all the types in the associated child dicts always
appeared corrupted, referencing nonexistent types from a parent objdump
couldn't find.
So adjust --ctf-parent so that rather than taking a section name it
takes a member name instead (if not specified, the name is ".ctf", which
is what GNU ld emits). Because the option was always useless before
now, this is expected to have no backward-compatibility implications.
As part of this, we have to slightly adjust the code which skips the
archive member name if redundant: right now it skips it if it's ".ctf",
on the assumption that this name will almost always be at the start
of the objdump output and thus we'll end up with a shared dump
and then smaller, headed dumps for the per-TU child dicts; but if
the parent name has been changed, that won't be true any more.
So change the rules to "members named .ctf which appear first in the
first have their member name skipped". Since we now need to count
members, move from ctf_archive_iter (for which passing in extra
parameters requires defining a new struct and is clumsy) to
ctf_archive_next, allowing us to just *call* dump_ctf_archive_member and
maintain a member count in the obvious way. In the process we fix a
tiny difference between readelf and objdump: if a ctf_dump ever failed,
readelf skipped every later member, while objdump tried to keep going as
much as it could. For a dumping tool the former is clearly preferable.
binutils/ChangeLog
2021-10-25 Nick Alcock <nick.alcock@oracle.com>
* objdump.c (usage): --ctf-parent now takes a name, not a section.
(dump_ctf): Don't open a separate section; use the parent_name in
ctf_dict_open instead. Use ctf_archive_next, not ctf_archive_iter,
so we can pass down a member count.
(dump_ctf_archive_member): Add the member count; don't return
anything. Import parents into children no matter what the
parent's name, while still avoiding displaying the header for the
common parent name of ".ctf".
* readelf.c (usage): Adjust similarly.
(dump_section_as_ctf): Likewise.
(dump_ctf_archive_member): Likewise. Never stop iterating over
archive members, even if ctf_dump of one member fails.
* doc/ctf.options.texi: Adjust.
Alan Modra [Mon, 25 Oct 2021 05:41:42 +0000 (16:11 +1030)]
objdump doesn't accept -L option
A followup to commit
ca0e11aa4b.
* objdump.c (main): Add 'L' to short options and sort them.
Alan Modra [Mon, 25 Oct 2021 05:12:40 +0000 (15:42 +1030)]
bfd_nonfatal_message, localise va_start
Nothing to see here, just a little tidier.
* bucomm.c (bfd_nonfatal_message): Localise va_list args.
Alan Modra [Mon, 25 Oct 2021 01:09:39 +0000 (11:39 +1030)]
ubsan: _bfd_xcoff64_swap_aux_in left shift of negative value
* coff64-rs6000.c (_bfd_xcoff64_swap_aux_in): Use bfd_vma for h.
Alan Modra [Sun, 24 Oct 2021 23:45:59 +0000 (10:15 +1030)]
asan: evax_bfd_print_image buffer overflow
* vms-alpha.c (evax_bfd_print_image): Sanity check printing of
"image activator fixup" section.
(evax_bfd_print_relocation_records): Sanity check buffer offsets.
(evax_bfd_print_address_fixups): Likewise.
(evax_bfd_print_reference_fixups): Likewise.
GDB Administrator [Mon, 25 Oct 2021 00:00:17 +0000 (00:00 +0000)]
Automatic date update in version.in
Alan Modra [Sun, 24 Oct 2021 09:57:06 +0000 (20:27 +1030)]
asan: c4x, c54x coff_canonicalize_reloc buffer overflow
Sometimes the investigation of a fuzzing bug report leads into areas
you'd rather not go. In this instance by the time I'd figured out the
real cause was a target variant that had never been properly supported
in binutils, the time needed to fix it was less than the time needed
to rip it out.
* coffcode.h (coff_set_alignment_hook): Call bfd_coff_swap_reloc_in
not coff_swap_reloc_in.
(coff_slurp_reloc_table): Likewise. Don't use RELOC type.
(ticoff0_swap_table): Use coff_swap_reloc_v0_out and
coff_swap_reloc_v0_in.
* coffswap.h (coff_swap_reloc_v0_in, coff_swap_reloc_v0_out): New.
* coff-tic54x.c (tic54x_lookup_howto): Don't abort.
* coffgen.c (coff_get_normalized_symtab): Use PTR_ADD.
* bfd-in.h (PTR_ADD, NPTR_ADD): Avoid warnings when passing an
expression.
* bfd-in2.h: Regenerate.
Alan Modra [Sun, 24 Oct 2021 08:06:03 +0000 (18:36 +1030)]
asan: arm-darwin: buffer overflow
PR 21813
* mach-o-arm.c (bfd_mach_o_arm_canonicalize_one_reloc): Sanity
check PAIR reloc in other branch of condition as was done for
PR21813. Formatting. Delete debug printf.
Alan Modra [Sat, 23 Oct 2021 00:57:14 +0000 (11:27 +1030)]
asan: aout: heap buffer overflow
* aoutx.h (aout_get_external_symbols): Sanity check before writing
zero index entry. Remove outdated comment.
* pdp11.c (aout_get_external_symbols): Likewise.
liuzhensong [Fri, 22 Oct 2021 08:42:07 +0000 (16:42 +0800)]
LoongArch ld support
2021-10-22 Chenghua Xu <xuchenghua@loongson.cn>
Zhensong Liu <liuzhensong@loongson.cn>
Weinan Liu <liuweinan@loongson.cn>
Xiaolin Tang <tangxiaolin@loongson.cn>
ld/
* Makefile.am: Add LoongArch.
* NEWS: Mention LoongArch support.
* configure.tgt: Add LoongArch.
* emulparams/elf32loongarch-defs.sh: New.
* emulparams/elf32loongarch.sh: Likewise.
* emulparams/elf64loongarch-defs.sh: Likewise.
* emulparams/elf64loongarch.sh: Likewise.
* emultempl/loongarchelf.em: Likewise.
* Makefile.in: Regenerate.
* po/BLD-POTFILES.in: Regenerate.
ld/testsuite/
* ld-loongarch-elf/disas-jirl.d: New.
* ld-loongarch-elf/disas-jirl.s: Likewise.
* ld-loongarch-elf/jmp_op.d: Likewise.
* ld-loongarch-elf/jmp_op.s: Likewise.
* ld-loongarch-elf/ld-loongarch-elf.exp: Likewise.
* ld-loongarch-elf/macro_op.d: Likewise.
* ld-loongarch-elf/macro_op.s: Likewise.
* ld-loongarch-elf/syscall-0.s: Likewise.
* ld-loongarch-elf/syscall-1.s: Likewise.
* ld-loongarch-elf/syscall.d: Likewise.
* ld-srec/srec.exp: Add LoongArch.
* ld-unique/pr21529.d: Likewise.
liuzhensong [Fri, 22 Oct 2021 08:42:06 +0000 (16:42 +0800)]
LoongArch gas support
2021-10-22 Chenghua Xu <xuchenghua@loongson.cn>
Zhensong Liu <liuzhensong@loongson.cn>
Weinan Liu <liuweinan@loongson.cn>
Xiaolin Tang <tangxiaolin@loongson.cn>
gas/
* Makefile.am: Add LoongArch.
* NEWS: Mention LoongArch support.
* config/loongarch-lex-wrapper.c: New.
* config/loongarch-lex.h: New.
* config/loongarch-lex.l: New.
* config/loongarch-parse.y: New.
* config/tc-loongarch.c: New.
* config/tc-loongarch.h: New.
* configure.ac: Add LoongArch.
* configure.tgt: Likewise.
* doc/as.texi: Likewise.
* doc/c-loongarch.texi: Likewise.
* Makefile.in: Regenerate.
* configure: Regenerate.
* po/POTFILES.in: Regenerate.
gas/testsuite/
* gas/all/gas.exp: Add LoongArch.
* gas/elf/elf.exp: Likewise.
* gas/loongarch/4opt_op.d: New.
* gas/loongarch/4opt_op.s: Likewise.
* gas/loongarch/fix_op.d: Likewise.
* gas/loongarch/fix_op.s: Likewise.
* gas/loongarch/float_op.d: Likewise.
* gas/loongarch/float_op.s: Likewise.
* gas/loongarch/imm_op.d: Likewise.
* gas/loongarch/imm_op.s: Likewise.
* gas/loongarch/jmp_op.d: Likewise.
* gas/loongarch/jmp_op.s: Likewise.
* gas/loongarch/load_store_op.d: Likewise.
* gas/loongarch/load_store_op.s: Likewise.
* gas/loongarch/loongarch.exp: Likewise.
* gas/loongarch/macro_op.d: Likewise.
* gas/loongarch/macro_op.s: Likewise.
* gas/loongarch/nop.d: Likewise.
* gas/loongarch/nop.s: Likewise.
* gas/loongarch/privilege_op.d: Likewise.
* gas/loongarch/privilege_op.s: Likewise.
* gas/loongarch/syscall.d: Likewise.
* gas/loongarch/syscall.s: Likewise.
* lib/gas-defs.exp: Add LoongArch.
liuzhensong [Fri, 22 Oct 2021 08:42:05 +0000 (16:42 +0800)]
LoongArch binutils support
2021-10-22 Chenghua Xu <xuchenghua@loongson.cn>
Zhensong Liu <liuzhensong@loongson.cn>
Weinan Liu <liuweinan@loongson.cn>
binutils/
* NEWS: Mention LoongArch support.
* readelf.c: Add LoongArch.
* testsuite/binutils-all/objdump.exp: Add LoongArch.
liuzhensong [Fri, 22 Oct 2021 08:42:04 +0000 (16:42 +0800)]
LoongArch opcodes support
2021-10-22 Chenghua Xu <xuchenghua@loongson.cn>
Zhensong Liu <liuzhensong@loongson.cn>
Weinan Liu <liuweinan@loongson.cn>
include/
* opcode/loongarch.h: New.
* dis-asm.h: Declare print_loongarch_disassembler_options.
opcodes/
* Makefile.am: Add LoongArch.
* configure.ac: Likewise.
* disassemble.c: Likewise.
* disassemble.h: Declare print_insn_loongarch.
* loongarch-coder.c: New.
* loongarch-dis.c: New.
* loongarch-opc.c: New.
* Makefile.in: Regenerate.
* configure: Regenerate.
* po/POTFILES.in: Regenerate.
liuzhensong [Fri, 22 Oct 2021 08:42:03 +0000 (16:42 +0800)]
LoongArch bfd support
2021-10-22 Chenghua Xu <xuchenghua@loongson.cn>
Zhensong Liu <liuzhensong@loongson.cn>
Weinan Liu <liuweinan@loongson.cn>
bfd/
* Makefile.am: Add LoongArch.
* archures.c: Likewise.
* config.bfd: Likewise.
* configure.ac: Likewise.
* cpu-loongarch.c: New.
* elf-bfd.h: Add LoongArch.
* elf.c: Add LoongArch elfcore_grok_xxx.
* elfnn-loongarch.c: New.
* elfxx-loongarch.c: New.
* elfxx-loongarch.h: New.
* reloc.c: Add LoongArch BFD RELOC ENUM.
* targets.c: Add LoongArch target.
* Makefile.in: Regenerate.
* bfd-in2.h: Regenerate.
* configure: Regenerate.
* libbfd.h: Regenerate.
* po/BLD-POTFILES.in: Regenerate.
* po/SRC-POTFILES.in: Regenerate.
include/
* elf/common.h: Add NT_LARCH_{CPUCFG,CSR,LSX,LASX}.
* elf/loongarch.h: New.
GDB Administrator [Sun, 24 Oct 2021 00:00:16 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Sat, 23 Oct 2021 00:00:18 +0000 (00:00 +0000)]
Automatic date update in version.in
H.J. Lu [Thu, 21 Oct 2021 13:15:31 +0000 (06:15 -0700)]
x86: Add -muse-unaligned-vector-move to assembler
Unaligned load/store instructions on aligned memory or register are as
fast as aligned load/store instructions on modern Intel processors. Add
a command-line option, -muse-unaligned-vector-move, to x86 assembler to
encode encode aligned vector load/store instructions as unaligned
vector load/store instructions.
* NEWS: Mention -muse-unaligned-vector-move.
* config/tc-i386.c (use_unaligned_vector_move): New.
(encode_with_unaligned_vector_move): Likewise.
(md_assemble): Call encode_with_unaligned_vector_move for
-muse-unaligned-vector-move.
(OPTION_MUSE_UNALIGNED_VECTOR_MOVE): New.
(md_longopts): Add -muse-unaligned-vector-move.
(md_parse_option): Handle -muse-unaligned-vector-move.
(md_show_usage): Add -muse-unaligned-vector-move.
* doc/c-i386.texi: Document -muse-unaligned-vector-move.
* testsuite/gas/i386/i386.exp: Run unaligned-vector-move and
x86-64-unaligned-vector-move.
* testsuite/gas/i386/unaligned-vector-move.d: New file.
* testsuite/gas/i386/unaligned-vector-move.s: Likewise.
* testsuite/gas/i386/x86-64-unaligned-vector-move.d: Likewise.
Tom Tromey [Tue, 19 Oct 2021 18:44:56 +0000 (12:44 -0600)]
Fix 'uninstall' target
This adds some missing code to the 'uninstall' targets in gdb and
gdbserver. It also changes gdb's uninstall target so that it no
longer tries to remove any man page -- this is already done (and more
correctly) by doc/Makefile.in.
I tested this with 'make install' followed by 'make uninstall', then
examining the install tree for regular files. Only the 'dir' file
remains, but this appears to just be how 'install-info' is intended to
work.
Tom Tromey [Tue, 19 Oct 2021 18:27:51 +0000 (12:27 -0600)]
Remove unused variables from gdbserver's Makefile
This removes a number of unused variables from gdbserver's Makefile.
I found these while working on the subsequent patches, and figured it
would be cleaner to have a separate patch for the deletions.
Tom de Vries [Fri, 22 Oct 2021 15:46:43 +0000 (17:46 +0200)]
[gdb/testsuite] Fix gdb.threads/linux-dp.exp
On openSUSE Tumbleweed with glibc-debuginfo installed I get:
...
(gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
where^M
#0 print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
#1 0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
#2 0x00007ffff7d56b37 in start_thread (arg=<optimized out>) \
at pthread_create.c:435^M
#3 0x00007ffff7ddb640 in clone3 () \
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81^M
(gdb) PASS: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
...
while without debuginfo installed I get instead:
...
(gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
where^M
#0 print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
#1 0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
#2 0x00007ffff7d56b37 in start_thread () from /lib64/libc.so.6^M
#3 0x00007ffff7ddb640 in clone3 () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
...
The problem is that the regexp used:
...
"\(from .*libpthread\|at pthread_create\|in pthread_create\)"
...
expects the 'from' part to match libpthread, but in glibc 2.34 libpthread has
been merged into libc.
Fix this by updating the regexp.
Tested on x86_64-linux.
Tom de Vries [Fri, 22 Oct 2021 15:42:37 +0000 (17:42 +0200)]
[gdb/testsuite] Fix FAILs in gdb.mi/mi-breakpoint-changed.exp
Since commit
e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in
mi_gdb_test" we run into:
...
PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: mi runto main
Expecting: ^(-break-insert -f pendfunc1[^M
]+)?((&.*)*.*~"Breakpoint 2 at.*\\n".*=breakpoint-created,\
bkpt=\{number="2",type="breakpoint".*\}.*\n\^done[^M
]+[(]gdb[)] ^M
[ ]*)
-break-insert -f pendfunc1^M
^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",\
addr="0x00007ffff7bd559e",func="pendfunc1",\
file="gdb/testsuite/gdb.mi/pendshr1.c",\
fullname="gdb/testsuite/gdb.mi/pendshr1.c",line="21",thread-groups=["i1"],\
times="0",original-location="pendfunc1"}^M
(gdb) ^M
FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
-break-insert -f pendfunc1 (unexpected output)
...
The regexp expects a breakpoint-created event, but that's actually suppressed
by the command:
...
DEF_MI_CMD_MI_1 ("break-insert", mi_cmd_break_insert,
&mi_suppress_notification.breakpoint),
...
Fix this by updating the regexp.
Likewise for the following:
...
PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
-break-insert -f pendfunc1
Expecting: ^(-break-enable count 1 2[^M
]+)?(=breakpoint-modified,\
bkpt=\{number="2",type="breakpoint",disp="dis",enabled="y".*\}.*\n\^done[^M
]+[(]gdb[)] ^M
[ ]*)
-break-enable count 1 2^M
^done^M
(gdb) ^M
FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
-break-enable count 1 2 (unexpected out\
put)
...
Tested on x86_64-linux.
Andrew Burgess [Thu, 16 Sep 2021 17:30:35 +0000 (18:30 +0100)]
gdb/python: move gdb.Membuf support into a new file
In a future commit I'm going to be creating gdb.Membuf objects from a
new file within gdb/python/py*.c. Currently all gdb.Membuf objects
are created directly within infpy_read_memory (as a result of calling
gdb.Inferior.read_memory()).
Initially I split out the Membuf creation code into a new function,
and left the new function in gdb/python/py-inferior.c, however, it
felt a little random that the Membuf creation code should live with
the inferior handling code.
So, then I moved all of the Membuf related code out into a new file,
gdb/python/py-membuf.c, the interface is gdbpy_buffer_to_membuf, which
wraps an array of bytes into a gdb.Membuf object.
Most of the code is moved directly from py-inferior.c with only minor
tweaks to layout and replacing NULL with nullptr, hence, I've left the
copyright date on py-membuf.c as 2009-2021 to match py-inferior.c.
Currently, the only user of this code is still py-inferior.c, but in
later commits this will change.
There should be no user visible changes after this commit.
Andrew Burgess [Wed, 15 Sep 2021 12:34:14 +0000 (13:34 +0100)]
gdb/python: new gdb.architecture_names function
Add a new function to the Python API, gdb.architecture_names(). This
function returns a list containing all of the supported architecture
names within the current build of GDB.
The values returned in this list are all of the possible values that
can be returned from gdb.Architecture.name().
Andrew Burgess [Wed, 13 Oct 2021 17:18:12 +0000 (18:18 +0100)]
gdb: make disassembler fprintf callback a static member function
The disassemble_info structure has four callbacks, we have three of
them as static member functions within gdb_disassembler, the fourth is
just a global static function.
However, this fourth callback, is still only used from the
disassemble_info struct, so there's no real reason for its special
handling.
This commit makes fprintf_disasm a static method within
gdb_disassembler.
There should be no user visible changes after this commit.
Lewis Revill [Fri, 22 Oct 2021 03:32:46 +0000 (11:32 +0800)]
RISC-V: Added ld testcase for pcgp relaxation.
Consider the the pcgp-relax-02 testcase,
.text
.globl _start
_start:
.L1: auipc a0, %pcrel_hi(data_a)
.L2: auipc a1, %pcrel_hi(data_b)
addi a0, a0, %pcrel_lo(.L1)
addi a1, a1, %pcrel_lo(.L2)
.data
.word 0x0
.globl data_a
data_a:
.word 0x1
.section .rodata
.globl data_b
data_b:
.word 0x2
If the first auipc is deleted, but we are still building the pcgp
table (connect the high and low pcrel relocations), then there is
an aliasing issue that we need some way to disambiguate which of
the two symbols we are targeting. Therefore, Palmer thought of a
way to use R_RISCV_DELETE to split this into two phases, so we
could resolve the addresses before creating the ambiguities.
This patch just add the ld testcase for the above case, in case we
have changed something but break this.
ld/
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Renamed pcgp-relax
to pcgp-relax-01, and added pcgp-relax-02.
* testsuite/ld-riscv-elf/pcgp-relax-01.d: Renmaed from pcgp-relax.
* testsuite/ld-riscv-elf/pcgp-relax-01.s: Likewise.
* testsuite/ld-riscv-elf/pcgp-relax-02.d: New testcase.
* testsuite/ld-riscv-elf/pcgp-relax-02.s: Likewise.
Lewis Revill [Thu, 21 Oct 2021 03:15:47 +0000 (11:15 +0800)]
RISC-V: Don't separate pcgp relaxation to another relax pass.
Commit
abd20cb637008da9d32018b4b03973e119388a0a and
ebdcad3fddf6ec21f6d4dcc702379a12718cf0c4 introduced additional
complexity into the paths run by the RISC-V relaxation pass in order to
resolve the issue of accurately keeping track of pcrel_hi and pcrel_lo
pairs. The first commit split up relaxation of these relocs into a pass
which occurred after other relaxations in order to prevent the situation
where bytes were deleted in between a pcrel_lo/pcrel_hi pair, inhibiting
our ability to find the corresponding pcrel_hi relocation from the
address attached to the pcrel_lo.
Since the relaxation was split into two passes the 'again' parameter
could not be used to perform the entire relaxation process again and so
the second commit added a way to restart ldelf_map_segments, thus
starting the whole process again.
Unfortunately this process could not account for the fact that we were
not finished with the relaxation process so in some cases - such as the
case where code would not fit in a memory region before the
R_RISCV_ALIGN relocation was relaxed - sanity checks in generic code
would fail.
This patch fixes all three of these concerns by reverting back to a
system of having only one target relax pass but updating entries in the
table of pcrel_hi/pcrel_lo relocs every time any bytes are deleted. Thus
we can keep track of the pairs accurately, and we can use the 'again'
parameter to restart the entire target relax pass, behaving in the way
that generic code expects. Unfortunately we must still have an
additional pass to delay deleting AUIPC bytes to avoid ambiguity between
pcrel_hi relocs stored in the table after deletion. This pass can only
be run once so we may potentially miss out on relaxation opportunities
but this is likely to be rare.
https://sourceware.org/bugzilla/show_bug.cgi?id=28410
bfd/
* elfnn-riscv.c (riscv_elf_link_hash_table): Removed restart_relax.
(riscv_elf_link_hash_table_create): Updated.
(riscv_relax_delete_bytes): Moved after the riscv_update_pcgp_relocs.
Update the pcgp_relocs table whenever bytes are deleted.
(riscv_update_pcgp_relocs): Add function to update the section
offset of pcrel_hi and pcrel_lo, and also update the symbol value
of pcrel_hi.
(_bfd_riscv_relax_call): Need to update the pcgp_relocs table
when deleting codes.
(_bfd_riscv_relax_lui): Likewise.
(_bfd_riscv_relax_tls_le): Likewise.
(_bfd_riscv_relax_align): Once we've handled an R_RISCV_ALIGN,
we can't relax anything else, so set the sec->sec_flg0 to true.
Besides, we don't need to update the pcgp_relocs table at this
stage, so just pass NULL pointer as the pcgp_relocs table for
riscv_relax_delete_bytes.
(_bfd_riscv_relax_section): Use only one pass for all target
relaxations.
(_bfd_riscv_relax_delete): Likewise, we don't need to update
the pcgp_relocs table at this stage, and don't need to set
the `again' since restart_relax mechanism is abandoned.
(bfd_elfNN_riscv_restart_relax_sections): Removed.
(_bfd_riscv_relax_section): Updated.
* elfxx-riscv.h (bfd_elf32_riscv_restart_relax_sections): Removed.
(bfd_elf64_riscv_restart_relax_sections): Likewise.
ld/
* emultempl/riscvelf.em: Revert restart_relax changes and set
relax_pass to 3.
* testsuite/ld-riscv-elf/align-small-region.d: New testcase.
* testsuite/ld-riscv-elf/align-small-region.ld: Likewise.
* testsuite/ld-riscv-elf/align-small-region.s: Likewise.
* testsuite/ld-riscv-elf/restart-relax.d: Removed sine the
restart_relax mechanism is abandoned.
* testsuite/ld-riscv-elf/restart-relax.s: Likewise.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
Simon Marchi [Fri, 22 Oct 2021 04:13:43 +0000 (00:13 -0400)]
gdb: fix remote-sim.c build
Commit
183be222907a ("gdb, gdbserver: make target_waitstatus safe")
broke the remote-sim.c build. In fact, it does some wrong changes,
result of a bad sed invocation.
Fix it by adjusting the code to the new target_waitstatus API.
Change-Id: I3236ff7ef7681fc29215f68be210ff4263760e91
GDB Administrator [Fri, 22 Oct 2021 00:00:17 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Thu, 21 Oct 2021 20:12:04 +0000 (16:12 -0400)]
gdb, gdbserver: make target_waitstatus safe
I stumbled on a bug caused by the fact that a code path read
target_waitstatus::value::sig (expecting it to contain a gdb_signal
value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED. This
meant that the active union field was in fact
target_waitstatus::value::related_pid, and contained a ptid. The read
signal value was therefore garbage, and that caused GDB to crash soon
after. Or, since that GDB was built with ubsan, this nice error
message:
/home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value
2686365, which is not a valid value for type 'gdb_signal'
Despite being a large-ish change, I think it would be nice to make
target_waitstatus safe against that kind of bug. As already done
elsewhere (e.g. dynamic_prop), validate that the type of value read from
the union matches what is supposed to be the active field.
- Make the kind and value of target_waitstatus private.
- Make the kind initialized to TARGET_WAITKIND_IGNORE on
target_waitstatus construction. This is what most users appear to do
explicitly.
- Add setters, one for each kind. Each setter takes as a parameter the
data associated to that kind, if any. This makes it impossible to
forget to attach the associated data.
- Add getters, one for each associated data type. Each getter
validates that the data type fetched by the user matches the wait
status kind.
- Change "integer" to "exit_status", "related_pid" to "child_ptid",
just because that's more precise terminology.
- Fix all users.
That last point is semi-mechanical. There are a lot of obvious changes,
but some less obvious ones. For example, it's not possible to set the
kind at some point and the associated data later, as some users did.
But in any case, the intent of the code should not change in this patch.
This was tested on x86-64 Linux (unix, native-gdbserver and
native-extended-gdbserver boards). It was built-tested on x86-64
FreeBSD, NetBSD, MinGW and macOS. The rest of the changes to native
files was done as a best effort. If I forgot any place to update in
these files, it should be easy to fix (unless the change happens to
reveal an actual bug).
Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7
Simon Marchi [Tue, 28 Sep 2021 20:38:43 +0000 (16:38 -0400)]
gdbserver: initialize the members of lwp_info in-class
Add a constructor to initialize the waitstatus members. Initialize the
others in the class directly.
Change-Id: I10f885eb33adfae86e3c97b1e135335b540d7442
Simon Marchi [Tue, 28 Sep 2021 20:02:29 +0000 (16:02 -0400)]
gdbserver: make thread_info non-POD
Add a constructor and a destructor. The constructor takes care of the
initialization that happened in add_thread, while the destructor takes
care of the freeing that happened in free_one_thread. This is needed to
make target_waitstatus non-POD, as thread_info contains a member of that
type.
Change-Id: I1db321b4de9dd233ede0d5c101950f1d6f1d13b7
Andrew Pinski [Thu, 21 Oct 2021 17:02:44 +0000 (17:02 +0000)]
Fix ARMv8.4 for hw watchpoint and breakpoint
Just like my previoius patch for ARMv8.1 and v8.2 (
49ecef2a7da2ee9df4),
this adds ARMv8.4 debug arch as being compatible for hw watchpoint
and breakpoints.
Andrew Pinski [Thu, 21 Oct 2021 16:57:36 +0000 (16:57 +0000)]
Refactor code slightly in nat/aarch64-linux-hw-point.c (aarch64_linux_get_debug_reg_capacity)
Since the two locations which check the debug arch are the same code currently, it is
a good idea to factor it out to a new function and just use that function from
aarch64_linux_get_debug_reg_capacity. This is also the first step to support
ARMv8.4 debug arch.
Carl Love [Wed, 20 Oct 2021 00:02:09 +0000 (00:02 +0000)]
Fixes for gdb.mi/mi-break.exp
Update the expected pattern for two of the tests.
Matching pattern \" doesn't work. Use .* to match the \* pattern.
Tom de Vries [Thu, 21 Oct 2021 15:48:07 +0000 (17:48 +0200)]
[gdb/tui] Fix breakpoint display functionality
In commit
81e6b8eb208 "Make tui-winsource not use breakpoint_chain", a loop
body was transformed into a lambda function body:
...
- for (bp = breakpoint_chain;
- bp != NULL;
- bp = bp->next)
+ iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
...
and consequently:
- a continue was replaced by a return, and
- a final return was added.
Then in commit
240edef62f0 "gdb: remove iterate_over_breakpoints function", we
transformed back to a loop body:
...
- iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
+ for (breakpoint *bp : all_breakpoints ())
...
but without reverting the changes that introduced the two returns.
Consequently, breakpoints no longer show up in the tui source window.
Fix this by reverting the changes that introduced the two returns.
Build on x86_64-linux, tested with all .exp test-cases that contain
tuiterm_env.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28483
Carl Love [Wed, 13 Oct 2021 22:32:06 +0000 (22:32 +0000)]
Fix test step-and-next-inline.cc
The test expect the runto_main to stop at the first line of the function.
Depending on the optimization level, gdb may stop in the prolog or after
the prolog at the first line. To ensure the test stops at the first line
of main, have it explicitly stop at a break point on the first line of the
function.
On PowerPC, the test passes when compiled with no optimization but fails
with all levels of optimization due to gdb stopping in the prolog.
Tom Tromey [Tue, 19 Oct 2021 19:10:27 +0000 (13:10 -0600)]
Fix latent Ada bug when accessing field offsets
The "add accessors for field (and call site) location" patch caused a
gdb crash when running the internal AdaCore testsuite. This turned
out to be a latent bug in ada-lang.c.
The immediate cause of the bug is that find_struct_field
unconditionally uses TYPE_FIELD_BITPOS. This causes an assert for a
dynamic type.
This patch fixes the problem by doing two things. First, it changes
find_struct_field to use a dummy value for the field offset in the
situation where the offset is not actually needed by the caller. This
works because the offset isn't used in any other way -- only as a
result.
Second, this patch assures that calls to find_struct_field use a
resolved type when the offset is needed. For
value_tag_from_contents_and_address, this is done by resolving the
type explicitly. In ada_value_struct_elt, this is done by passing
nullptr for the out parameters when they are not needed (the second
call in this function already uses a resolved type).
Note that, while we believe the parent field probably can't occur at a
variable offset, the patch still updates this code path, just in case.
I've updated an existing test case to reproduce the crash.
I'm checking this in.
Alan Modra [Thu, 21 Oct 2021 08:48:34 +0000 (19:18 +1030)]
-Waddress warning in ldelf.c
ldelf.c: In function 'ldelf_after_open':
ldelf.c:1049:43: warning: the comparison will always evaluate as 'true' for the address of 'elf_header' will never be NULL [-Waddress]
1049 | && elf_tdata (abfd)->elf_header != NULL
| ^~
In file included from ldelf.c:37:
../bfd/elf-bfd.h:1957:21: note: 'elf_header' declared here
1957 | Elf_Internal_Ehdr elf_header[1]; /* Actual data, but ref like ptr */
* ldelf.c (ldelf_after_open): Remove useless elf_header test.
Alan Modra [Thu, 21 Oct 2021 06:32:06 +0000 (17:02 +1030)]
Avoid -Waddress warnings in readelf
Mainline gcc:
readelf.c: In function 'find_section':
readelf.c:349:8: error: the comparison will always evaluate as 'true' for the pointer operand in 'filedata->section_headers + (sizetype)((long unsigned int)i * 80)' must not be NULL [-Werror=address]
349 | ((X) != NULL \
| ^~
readelf.c:761:9: note: in expansion of macro 'SECTION_NAME_VALID'
761 | if (SECTION_NAME_VALID (filedata->section_headers + i)
| ^~~~~~~~~~~~~~~~~~
This will likely be fixed in gcc, but inline functions are nicer than
macros.
* readelf.c (SECTION_NAME, SECTION_NAME_VALID),
(SECTION_NAME_PRINT, VALID_SYMBOL_NAME, VALID_DYNAMIC_NAME),
(GET_DYNAMIC_NAME): Delete. Replace with..
(section_name, section_name_valid, section_name_print),
(valid_symbol_name, valid_dynamic_name, get_dynamic_name): ..these
new inline functions. Update use throughout file.
GDB Administrator [Thu, 21 Oct 2021 00:00:22 +0000 (00:00 +0000)]
Automatic date update in version.in
Alan Modra [Tue, 19 Oct 2021 23:39:57 +0000 (10:09 +1030)]
PR28417, std::string no longer allows accepting nullptr_t
PR 28417
* incremental.cc (Sized_relobj_incr::do_section_name): Avoid
std:string undefined behaviour.
* options.h (Search_directory::Search_directory): Likewise.
Alan Modra [Tue, 19 Oct 2021 22:42:48 +0000 (09:12 +1030)]
Re: PR27625, powerpc64 gold __tls_get_addr calls
My previous PR27625 patch had a problem or two. For one, the error
"__tls_get_addr call lacks marker reloc" on processing some calls
before hitting a call without markers typically isn't seen. Instead a
gold assertion fails. Either way it would be a hard error, which
triggers on a file contained in libphobos.a when running the gcc
testsuite. A warning isn't even appropriate since the call involved
is one built by hand without any of the arg setup relocations that
might result in linker optimisation.
So this patch reverts most of commit
0af4fcc25dd5, instead entirely
ignoring the problem of mis-optimising old-style __tls_get_addr calls
without marker relocs. We can't handle them gracefully without
another pass over relocations before decisions are made about GOT
entries in Scan::global or Scan::local. That seems too costly, just
to link object files from 2009. What's more, there doesn't seem to be
any way to allow the libphobos explicit __tls_get_addr call, but not
old TLS sequences without marker relocs. Examining instructions
before the __tls_get_addr call is out of the question: program flow
might reach the call via a branch. Putting an R_PPC64_TLSGD marker
with zero sym on the call might be a solution, but current linkers
will then merrily optimise away the call!
PR gold/27625
* powerpc.cc (Powerpc_relobj): Delete no_tls_marker_, tls_marker_,
and tls_opt_error_ variables and accessors. Remove all uses.
Tom Tromey [Sun, 3 Oct 2021 14:16:50 +0000 (08:16 -0600)]
Use std::string in print_one_catch_syscall
This changes print_one_catch_syscall to use std::string, removing a
bit of manual memory management.
Tom Tromey [Sat, 2 Oct 2021 23:17:27 +0000 (17:17 -0600)]
Use unique_xmalloc_ptr in breakpoint
This changes struct breakpoint to use unique_xmalloc_ptr in a couple
of spots, removing a bit of manual memory management.
Tom Tromey [Sat, 2 Oct 2021 22:58:49 +0000 (16:58 -0600)]
Use unique_xmalloc_ptr in bp_location
This changes struct bp_location to use a unique_xmalloc_ptr, removing
a bit of manual memory management.
Tom Tromey [Sat, 2 Oct 2021 22:49:54 +0000 (16:49 -0600)]
Use unique_xmalloc_ptr in watchpoint
This changes struct watchpoint to use unique_xmalloc_ptr in a couple
of places, removing a bit of manual memory management.
Tom Tromey [Sat, 2 Oct 2021 22:43:49 +0000 (16:43 -0600)]
Use unique_xmalloc_ptr in exec_catchpoint
This changes struct exec_catchpoint to use a unique_xmalloc_ptr,
removing a bit of manual memory management.
Tom Tromey [Sat, 2 Oct 2021 22:40:00 +0000 (16:40 -0600)]
Use unique_xmalloc_ptr in solib_catchpoint
This changes struct solib_catchpoint to use a unique_xmalloc_ptr,
removing a bit of manual memory management.
Christian Biesinger [Fri, 8 Oct 2021 20:09:46 +0000 (16:09 -0400)]
Make c-exp.y work with Bison 3.8+
When using Bison 3.8, we get this error:
../../gdb/c-exp.y:3455:1: error: 'void c_print_token(FILE*, int, YYSTYPE)' defined but not used [-Werror=unused-function]
That's because bison 3.8 removed YYPRINT support:
https://savannah.gnu.org/forum/forum.php?forum_id=10047
Accordingly, this patch only defines that function for Bison < 3.8.
Change-Id: I3cbf2f317630bb72810b00f2d9b2c4b99fa812ad
GDB Administrator [Wed, 20 Oct 2021 00:00:09 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom de Vries [Tue, 19 Oct 2021 21:50:50 +0000 (23:50 +0200)]
[gdb/testsuite] Reimplement gdb.gdb/python-interrupts.exp as unittest
The test-case gdb.gdb/python-interrupts.exp:
- runs to captured_command_loop
- sets a breakpoint at set_active_ext_lang
- calls a python command
- verifies the command triggers the breakpoint
- sends a signal and verifies the result
The test-case is fragile, because (f.i. with -flto) it cannot be guaranteed
that captured_command_loop and set_active_ext_lang are available for setting
breakpoints.
Reimplement the test-case as unittest, using:
- execute_command_to_string to capture the output
- try/catch to catch the "Error while executing Python code" exception
- a new hook selftests::hook_set_active_ext_lang to raise the signal
Tested on x86_64-linux.
Tom Tromey [Mon, 18 Oct 2021 18:32:18 +0000 (12:32 -0600)]
Check index in type::field
This changes gdb to check the index that is passed to type::field.
This caught one bug in the Ada code when running the test suite
(actually I found the bug first, then realized that the check would
have helped), so this patch fixes that as well.
Regression tested on x86-64 Fedora 34.
Tom Tromey [Thu, 30 Sep 2021 18:53:55 +0000 (12:53 -0600)]
Fix Rust lex selftest when using libiconv
The Rust lex selftest fails on our Windows build. I tracked this down
to a use of UTF-32 as a parameter to convert_between_encodings. Here,
iconv_open succeeds, but the actual conversion of a tab character
fails with EILSEQ. I suspect that "UTF-32" is being interpreted as
big-endian, as changing the call to use "UTF-32LE" makes it work.
This patch implements this fix.
Tom Tromey [Wed, 29 Sep 2021 18:51:15 +0000 (12:51 -0600)]
Fix format_pieces selftest on Windows
The format_pieces selftest currently fails on Windows hosts.
The selftest doesn't handle the "%ll" -> "%I64" rewrite that the
formatter may perform, but also gdbsupport was missing a configure
check for PRINTF_HAS_LONG_LONG. This patch fixes both issues.
Tom Tromey [Fri, 24 Sep 2021 20:06:52 +0000 (14:06 -0600)]
Fix bug in dynamic type resolution
A customer-reported problem led us to a bug in dynamic type
resolution. resolve_dynamic_struct will recursively call
resolve_dynamic_type_internal, passing it the sub-object for the
particular field being resolved. While it offsets the address here,
it does not also offset the "valaddr" -- the array of bytes describing
the memory.
This patch fixes the bug, by offsetting both. A test case is included
that can be used to reproduce the bug.
Tom Tromey [Thu, 23 Sep 2021 19:09:48 +0000 (13:09 -0600)]
Always use std::function for self-tests
Now that there is a register_test variant that accepts std::function,
it seems to me that the 'selftest' struct and accompanying code is
obsolete -- simply always using std::function is simpler. This patch
implements this idea.
Daniel Black [Mon, 18 Oct 2021 06:06:47 +0000 (17:06 +1100)]
Fix PR gdb/17917 Lookup build-id in remote binaries
GDB doesn't support loading debug files using build-id from remote
target filesystems.
This is the case when gdbserver attached to a process and a gdb target
remote occurs over tcp.
With this change we make build-id lookups possible:
(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is "/usr/local/lib/debug".
(gdb) set debug-file-directory /usr/lib/debug
(gdb) show sysroot
The current system root is "target:".
(gdb) target extended-remote :46615
Remote debugging using :46615
warning: Can not parse XML target description; XML support was disabled at compile time
Reading /usr/sbin/mariadbd from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /usr/sbin/mariadbd from remote target...
Reading symbols from target:/usr/sbin/mariadbd...
Reading /usr/lib/debug/.build-id/6e/
0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Reading /usr/lib/debug/.build-id/6e/
0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Reading symbols from target:/usr/lib/debug/.build-id/6e/
0a874dca5a7ff831396ddc0785d939a192efe3.debug...
Reading /lib/x86_64-linux-gnu/libpcre2-8.so.0 from remote target...
...
Before this change, the lookups would have been (GNU gdb (GDB) Fedora 10.2-3.fc34):
(gdb) target extended-remote :46615
Remote debugging using :46615
Reading /usr/sbin/mariadbd from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /usr/sbin/mariadbd from remote target...
Reading symbols from target:/usr/sbin/mariadbd...
Reading /usr/sbin/
0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Reading /usr/sbin/.debug/
0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Reading /usr/lib/debug//usr/sbin/
0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Reading /usr/lib/debug/usr/sbin//
0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Reading target:/usr/lib/debug/usr/sbin//
0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
Missing separate debuginfo for target:/usr/sbin/mariadbd
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/6e/
0a874dca5a7ff831396ddc0785d939a192efe3.debug
(No debugging symbols found in target:/usr/sbin/mariadbd)
Observe it didn't look for
/usr/lib/debug/.build-id/6e/
0a874dca5a7ff831396ddc0785d939a192efe3.debug
on the remote target (where it is) and expected them to be installed
locally.
As a minor optimization, this also changes the build-id lookup such that
if sysroot is empty, no second lookup of the same location is performed.
Change-Id: I5181696d271c325a25a0805a8defb8ab7f9b3f55
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17917
Nick Clifton [Tue, 19 Oct 2021 15:02:49 +0000 (16:02 +0100)]
Fix a potential illegal memory access when testing for a special LTO symbol name.
bfd * linker.c (_bfd_generic_link_add_one_symbol): Test for a NULL
name before checking to see if the symbol is __gnu_lto_slim.
* archive.c (_bfd_compute_and_write_armap): Likewise.
binutils
* nm.c (filter_symbols): Test for a NULL name before checking to
see if the symbol is __gnu_lto_slim.
* objcopy.c (filter_symbols): Likewise.
GDB Administrator [Tue, 19 Oct 2021 00:00:14 +0000 (00:00 +0000)]
Automatic date update in version.in
Weimin Pan [Mon, 18 Oct 2021 18:15:21 +0000 (14:15 -0400)]
CTF: incorrect underlying type setting for enumeration types
A bug was filed against the incorrect underlying type setting for
an enumeration type, which was caused by a copy and paste error.
This patch fixes the problem by setting it by calling objfile_int_type,
which was originally dwarf2_per_objfile::int_type, with ctf_type_size bits.
Also add error checking on ctf_func_type_info call.
GDB Administrator [Mon, 18 Oct 2021 00:00:08 +0000 (00:00 +0000)]
Automatic date update in version.in
Alan Modra [Sun, 17 Oct 2021 07:04:46 +0000 (17:34 +1030)]
PR28459, readelf issues bogus warning
I'd missed the fact that the .debug_rnglists dump doesn't exactly
display the contents of the section. Instead readelf rummages through
.debug_info looking for DW_AT_ranges entries, then displays the
entries in .debug_rnglists pointed at, sorted. A simpler dump of the
actual section contents might be more useful and robust, but it was
likely done that way to detect overlap and holes.
Anyway, the headers in .debug_rnglists besides the first are ignored,
and limiting to the unit length of the first header fails if there is
more than one unit.
PR 28459
* dwarf.c (display_debug_ranges): Don't constrain data to length
in header.
GDB Administrator [Sun, 17 Oct 2021 00:00:19 +0000 (00:00 +0000)]
Automatic date update in version.in
H.J. Lu [Sat, 16 Oct 2021 15:12:25 +0000 (08:12 -0700)]
ld: Adjust pr28158.rd for glibc 2.34
Adjust pr28158.rd for glibc 2.34:
$ readelf -W --dyn-syms tmpdir/pr28158
Symbol table '.dynsym' contains 4 entries:
Num: Value Size Type Bind Vis Ndx Name
0:
0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1:
0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.34 (2)
2:
0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
3:
000000000040401c 4 OBJECT GLOBAL DEFAULT 23 foo@VERS_2.0 (3)
$
vs older glibc:
$ readelf -W --dyn-syms tmpdir/pr28158
Symbol table '.dynsym' contains 4 entries:
Num: Value Size Type Bind Vis Ndx Name
0:
0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1:
0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (3)
2:
0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
3:
000000000040401c 4 OBJECT GLOBAL DEFAULT 23 foo@VERS_2.0 (2)
$
* testsuite/ld-elf/pr28158.rd: Adjusted for glibc 2.34.
GDB Administrator [Sat, 16 Oct 2021 00:00:15 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 15 Oct 2021 00:00:12 +0000 (00:00 +0000)]
Automatic date update in version.in
Carl Love [Wed, 13 Oct 2021 20:28:48 +0000 (20:28 +0000)]
Powerpc: Add support for openat and fstatat syscalls
[gdb] update ppc-linux-tdep.c
Add argument to ppc_canonicalize_syscall for the wordsize.
Add syscall entries for the openat and fstatat system calls.
Tom de Vries [Thu, 14 Oct 2021 14:58:21 +0000 (16:58 +0200)]
[gdb/testsuite] Add .debug_loc support in dwarf assembler
Add .debug_loc support in the dwarf assembler, and use it in new test-case
gdb.dwarf2/loc-sec-offset.exp (which is based on
gdb.dwarf2/loclists-sec-offset.exp).
Tested on x86_64-linux.
Alan Modra [Thu, 14 Oct 2021 06:31:06 +0000 (17:01 +1030)]
[GOLD] Re: PowerPC64: Don't pretend to support multi-toc
We can't get at section->address() until everything is laid out, so
trying to generalise the offset calculation rather than using a value
of 0x8000 (the old object->toc_base_offset()) was bound to fail.
got->g_o_t() is a little better than a hard-coded 0x8000.
* powerpc.cc (Target_powerpc::Scan::local, global): Don't use
toc_pointer() here.
Alan Modra [Fri, 8 Oct 2021 23:33:21 +0000 (10:03 +1030)]
[GOLD] Two GOT sections for PowerPC64
Split .got into two piece, one with the header and entries for small
model got entries, the other with entries for medium/large model got
entries. The idea is to better support mixed pcrel/non-pcrel code
where non-pcrel small-model .toc entries need to be within 32k of the
toc pointer.
* target.h (Target::tls_offset_for_local): Add got param.
(Target::tls_offset_for_global): Likewise.
(Target::do_tls_offset_for_local, do_tls_offset_for_global): Likewise.
* output.h (Output_data_got::Got_entry::write): Add got param.
* output.cc (Output_data_got::Got_entry::write): Likewise, pass to
tls_offset_for_local/global calls.
(Output_data_got::do_write): Adjust to suit.
* s390.cc (Target_s390::do_tls_offset_for_local): Likewise.
(Target_s390::do_tls_offset_for_global): Likewise.
* powerpc.cc (enum Got_type): Extend with small types, move from
class Target_powerpc.
(Target_powerpc::biggot_): New.
(Traget_powerpc::do_tls_offset_for_local, do_tls_offset_for_global,
got_size, got_section, got_base_offset): Handle biggot_.
(Target_powerpc::do_define_standard_symbols): Adjust.
(Target_powerpc::make_plt_section, do_finalize_sections): Likewise.
(Output_data_got_powerpc::Output_data_got_powerpc): Only make
64-bit header for small got section.
(Output_data_got_powerpc::g_o_t): Only return a result for small
got section.
(Output_data_got_powerpc::write): Only write small got section
header.
(Target_powerpc::Scan::local, global): Select small/big Got_type
and section to suit reloc.
(Target_powerpc::Relocate::relocate): Similarly.
(Sort_toc_sections): Rewrite.
Alan Modra [Tue, 12 Oct 2021 09:15:13 +0000 (19:45 +1030)]
[GOLD] PowerPC64: Don't pretend to support multi-toc
Code in powerpc.cc is pretending to support a per-object toc pointer
value, but powerpc gold has no real support for multi-toc. This patch
removes the pretense, tidying quite a lot in preparation for a
followup patch. If multi-toc is ever to be supported, don't revert
this patch but start by adding object parameter to toc_pointer() and
an object to Branch_stub_key.
* powerpc.cc (Powerpc_relobj::toc_base_offset): Delete.
(Target_powerpc::toc_pointer): New function. Use throughout.
(Target_powerpc::got_base_offset): New function. Use throughout..
(Output_data_got_powerpc::got_base_offset): ..in place of
this. Delete.
(Output_data_got_powerpc::Output_data_got_powerpc): Init
header_index_ to -1u for 64-bit, and make header here.
(Output_data_got_powerpc::set_final_data_size, reserve_ent): Don't
make 64-bit header here.
(Output_data_got_powerpc::g_o_t): Return toc pointer offset in
section for 64-bit. Use throughout.
(Stub_table): Remove toc_base_off_ from Branch_stub_key, and
object param on add_long_branch_entry and find_long_branch_entry.
Adjust all uses.
Alan Modra [Thu, 14 Oct 2021 02:36:16 +0000 (13:06 +1030)]
Re: s12z/disassembler: call memory_error_func when appropriate
Adjust for commit
ba7c18a48457.
* testsuite/gas/s12z/truncated.d: Update expected output.
GDB Administrator [Thu, 14 Oct 2021 00:00:12 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom de Vries [Wed, 13 Oct 2021 19:35:49 +0000 (21:35 +0200)]
[gdb/exp] Improve <error reading variable> message
When printing a variable x in a subroutine foo:
...
subroutine foo (x)
integer(4) :: x (*)
x(3) = 1
end subroutine foo
...
where x is an array with unknown bounds, we get:
...
$ gdb -q -batch outputs/gdb.fortran/array-no-bounds/array-no-bounds \
-ex "break foo" \
-ex run \
-ex "print x"
Breakpoint 1 at 0x4005cf: file array-no-bounds.f90, line 18.
Breakpoint 1, foo (x=...) at array-no-bounds.f90:18
18 x(3) = 1
$1 = <error reading variable>
...
Improve the error message by printing the details of the error, such that we
have instead:
...
$1 = <error reading variable: failed to get range bounds>
...
This is a change in gdb/valprint.c, and grepping through the sources reveals
that this is a common pattern.
Tested on x86_64-linux.
Carl Love [Fri, 8 Oct 2021 22:54:05 +0000 (22:54 +0000)]
PPC fix for stfiwx instruction (and additional stores with primary opcode of 31)
[gdb] Fix address being recorded in rs6000-tdep.c, ppc_process_record_op31.
The GDB record function was recording the variable addr that was passed in
rather than the calculated effective address (ea) by the
ppc_process_record_op31 function.
Andrew Burgess [Tue, 5 Oct 2021 14:10:12 +0000 (15:10 +0100)]
gdb: improve error reporting from the disassembler
If the libopcodes disassembler returns a negative value then this
indicates that the disassembly failed for some reason. In disas.c, in
the function gdb_disassembler::print_insn we can see how this is
handled; when we get a negative value back, we call the memory_error
function, which throws an exception.
The problem here is that the address used in the memory_error call is
gdb_disassembler::m_err_memaddr, which is set in
gdb_disassembler::dis_asm_memory_error, which is called from within
the libopcodes disassembler through the
disassembler_info::memory_error_func callback.
However, for this to work correctly, every time the libopcodes
disassembler returns a negative value, the libopcodes disassembler
must have first called the memory_error_func callback.
My first plan was to make m_err_memaddr a gdb::optional, and assert
that it always had a value prior to calling memory_error, however, a
quick look in opcodes/*-dis.c shows that there _are_ cases where a
negative value is returned without first calling the memory_error_func
callback, for example in arc-dis.c and cris-dis.c.
Now, I think that a good argument can be made that these disassemblers
must therefore be broken, except for the case where we can't read
memory, we should always be able to disassemble the memory contents to
_something_, even if it's just '.word 0x....'. However, I certainly
don't plan to go and fix all of the disassemblers.
What I do propose to do then, is make m_err_memaddr a gdb::optional,
but now, instead of always calling memory_error, I add a new path
which just calls error complaining about an unknown error. This new
path is only used if m_err_memaddr doesn't have a value (indicating
that the memory_error_func callback was not called).
To test this I just augmented one of the disassemblers to always
return -1, before this patch I see this:
Dump of assembler code for function main:
0x000101aa <+0>: Cannot access memory at address 0x0
And after this commit I now see:
Dump of assembler code for function main:
0x000101aa <+0>: unknown disassembler error (error = -1)
This doesn't really help much, but that's because there's no way to
report non memory errors out of the disasembler, because, it was not
expected that the disassembler would ever report non memory errors.
Tom de Vries [Wed, 13 Oct 2021 09:36:02 +0000 (11:36 +0200)]
[gdb/testsuite] Fix gdb.fortran/call-no-debug.exp with native-gdbserver
When running test-case gdb.fortran/call-no-debug.exp with target board
native-gdbserver, I run into:
...
(gdb) PASS: gdb.fortran/call-no-debug.exp: print string_func_ (&'abcdefg', 3)
call (integer) string_func_ (&'abcdefg', 3)^M
$2 = 0^M
(gdb) FAIL: gdb.fortran/call-no-debug.exp: call (integer) string_func_ (&'abcdefg', 3)
...
The problem is that gdb_test is used to match inferior output.
Fix this by using gdb_test_stdio.
Tested on x86_64-linux.
Tom de Vries [Wed, 13 Oct 2021 09:06:36 +0000 (11:06 +0200)]
[gdb/testsuite] Require use_gdb_stub == 0 where appropriate
When running with target board native-gdbserver, we run into a number of FAILs
due to use of the start command (and similar), which is not supported when
use_gdb_stub == 1.
Fix this by:
- requiring use_gdb_stub == 0 for the entire test-case, or
- guarding some tests in the test-case with use_gdb_stub == 0.
Tested on x86_64-linux.
Tom de Vries [Wed, 13 Oct 2021 09:06:36 +0000 (11:06 +0200)]
[gdb/testsuite] Fix test name in gdb.python/python.exp
When running test-case gdb.python/python.exp, we have:
...
PASS: gdb.python/python.exp: starti via gdb.execute, not from tty
PASS: gdb.python/python.exp: starti via interactive input
...
The two tests are instances of the same test, with different values for
starti command argument from_tty, so it's strange that the test names are so
different.
This is due to using a gdb_test nested in a gdb_test_multiple, with the inner
one using a different test name than the outer one. [ That could still make
sense if both produced passes, but that's not the case here. ]
Fix this by using $gdb_test_name, such that we have:
...
PASS: gdb.python/python.exp: starti via gdb.execute, not from tty
PASS: gdb.python/python.exp: starti via gdb.execute, from tty
...
Also make this more readable by using variables.
Tested on x86_64-linux.
Tom de Vries [Wed, 13 Oct 2021 09:06:36 +0000 (11:06 +0200)]
[gdb/testsuite] Fix gdb.base/batch-exit-status.exp with native-gdbserver
When running test-case gdb.base/batch-exit-status.exp with target board
native-gdbserver, I run into (added missing double quotes for clarity):
...
builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \
-data-directory $build/gdb/testsuite/../data-directory \
-iex "set height 0" -iex "set width 0" \
-ex "set auto-connect-native-target off" \
-iex "set sysroot" -batch ""^M
: No such file or directory.^M
PASS: gdb.base/batch-exit-status.exp: 1x: \
No such file or directory: [lindex $result 2] == 0
FAIL: gdb.base/batch-exit-status.exp: 1x: \
No such file or directory: [lindex $result 3] == $expect_status
...
As in commit
a02a90c114c "[gdb/testsuite] Set sysroot earlier in
local-board.exp", the problem is the use of -ex for
"set auto-connect-native-target off", which makes that the last command to
be executed, and consequently determines the return status.
Fix this by using -iex instead.
Tested on x86_64-linux.
Tom de Vries [Wed, 13 Oct 2021 09:06:36 +0000 (11:06 +0200)]
[gdb/testsuite] Remove quit in gdb.arch/i386-mpx.exp
When running test-case gdb.arch/i386-mpx.exp with target board
native-gdbserver, I run into:
...
(gdb) PASS: gdb.arch/i386-mpx.exp: verify size for bnd0
Remote debugging from host ::1, port 42328^M
quit^M
A debugging session is active.^M
^M
Inferior 1 [process 19679] will be killed.^M
^M
Quit anyway? (y or n) monitor exit^M
Please answer y or n.^M
A debugging session is active.^M
^M
Inferior 1 [process 19679] will be killed.^M
^M
Quit anyway? (y or n) WARNING: Timed out waiting for EOF in server after monitor exit
...
The problem is that the test-case sends a quit at the end (without verifying
the result of this in any way):
...
send_gdb "quit\n"
...
Fix this by removing the quit.
Tested on x86_64-linux.
GDB Administrator [Wed, 13 Oct 2021 00:00:06 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Tue, 12 Oct 2021 00:00:15 +0000 (00:00 +0000)]
Automatic date update in version.in
Srinath Parvathaneni [Wed, 21 Jul 2021 15:33:44 +0000 (12:33 -0300)]
[ARM] Add support for M-profile MVE extension
This patch adds support for the M-profile MVE extension, which includes the
following:
- New M-profile XML feature m-profile-mve
- MVE vector predication status and control register (VPR)
- p0 pseudo register (contained in the VPR)
- q0 ~ q7 pseudo vector registers
- New feature bits
- Documentation update
Pseudo register p0 is the least significant bits of vpr and can be accessed
as $p0 or displayed through $vpr. For more information about the register
layout, please refer to [1].
The q0 ~ q7 registers map back to the d0 ~ d15 registers, two d registers
per q register.
The register dump looks like this:
(gdb) info reg all
r0 0x0 0
r1 0x0 0
r2 0x0 0
r3 0x0 0
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x0 0x0 <__Vectors>
lr 0xffffffff -1
pc 0xd0c 0xd0c <Reset_Handler>
xpsr 0x1000000
16777216
d0 0 (raw 0x0000000000000000)
d1 0 (raw 0x0000000000000000)
d2 0 (raw 0x0000000000000000)
d3 0 (raw 0x0000000000000000)
d4 0 (raw 0x0000000000000000)
d5 0 (raw 0x0000000000000000)
d6 0 (raw 0x0000000000000000)
d7 0 (raw 0x0000000000000000)
d8 0 (raw 0x0000000000000000)
d9 0 (raw 0x0000000000000000)
d10 0 (raw 0x0000000000000000)
d11 0 (raw 0x0000000000000000)
d12 0 (raw 0x0000000000000000)
d13 0 (raw 0x0000000000000000)
d14 0 (raw 0x0000000000000000)
d15 0 (raw 0x0000000000000000)
fpscr 0x0 0
vpr 0x0 [ P0=0 MASK01=0 MASK23=0 ]
s0 0 (raw 0x00000000)
s1 0 (raw 0x00000000)
s2 0 (raw 0x00000000)
s3 0 (raw 0x00000000)
s4 0 (raw 0x00000000)
s5 0 (raw 0x00000000)
s6 0 (raw 0x00000000)
s7 0 (raw 0x00000000)
s8 0 (raw 0x00000000)
s9 0 (raw 0x00000000)
s10 0 (raw 0x00000000)
s11 0 (raw 0x00000000)
s12 0 (raw 0x00000000)
s13 0 (raw 0x00000000)
s14 0 (raw 0x00000000)
s15 0 (raw 0x00000000)
s16 0 (raw 0x00000000)
s17 0 (raw 0x00000000)
s18 0 (raw 0x00000000)
s19 0 (raw 0x00000000)
s20 0 (raw 0x00000000)
s21 0 (raw 0x00000000)
s22 0 (raw 0x00000000)
s23 0 (raw 0x00000000)
s24 0 (raw 0x00000000)
s25 0 (raw 0x00000000)
s26 0 (raw 0x00000000)
s27 0 (raw 0x00000000)
s28 0 (raw 0x00000000)
s29 0 (raw 0x00000000)
s30 0 (raw 0x00000000)
s31 0 (raw 0x00000000)
q0 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q1 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q2 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q3 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q4 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q5 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q6 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q7 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
p0 0x0 0
Built and regtested with a simulator.
[1] https://developer.arm.com/documentation/ddi0553/bn
Co-Authored-By: Luis Machado <luis.machado@linaro.org>
Luis Machado [Mon, 4 Oct 2021 16:56:43 +0000 (13:56 -0300)]
[ARM] Refactor pseudo register numbering
The pseudo register handling for ARM uses some hardcoded constants to
determine types and names. In preparation to the upcoming MVE support
patch (that will add another pseudo register), this patch refactors and
reorganizes things in order to simplify handling of future pseudo registers.
We keep track of the first pseudo register number in a group and the number of
pseudo registers in that group.
Right now we only have the S and Q pseudo registers.
Luis Machado [Mon, 4 Oct 2021 12:34:50 +0000 (09:34 -0300)]
[ARM] Small refactoring of arm gdbarch initialization
This is in preparation to MVE support, where we will define another
pseudo register. We need to define the pseudo register numbers *after*
accounting for all the registers in the XML description, so move
the call to tdesc_use_registers up.
If we don't do it, GDB's register count won't consider registers contained
in the XML but ignored by GDB, throwing the register numbering off.
Luis Machado [Tue, 27 Jul 2021 14:36:33 +0000 (11:36 -0300)]
[ARM] Refactor some constants
In preparation for the MVE extension patch, this one refactors some of
the register-related constants we have for ARM.
Basically I'm separating counting constants from numbering constants.
For example, ARM_A1_REGNUM is a numbering constant, whereas ARM_NUM_ARG_REGS
is a counting constant.
Tom de Vries [Mon, 11 Oct 2021 14:59:56 +0000 (16:59 +0200)]
[gdb/testsuite] Fix FAIL in gdb.mi/mi-var-child-f.exp
When running test-case gdb.mi/mi-var-child-f.exp on openSUSE Tumbleweed
(with glibc 2.34) I run into:
...
(gdb) ^M
PASS: gdb.mi/mi-var-child-f.exp: mi runto prog_array
Expecting: ^(-var-create array \* array[^M
]+)?(\^done,name="array",numchild="[0-9]+",value=".*",type=.*,has_more="0"[^M
]+[(]gdb[)] ^M
[ ]*)
-var-create array * array^M
&"Attempt to use a type name as an expression.\n"^M
^error,msg="-var-create: unable to create variable object"^M
(gdb) ^M
FAIL: gdb.mi/mi-var-child-f.exp: create local variable array (unexpected output)
...
The problem is that the name array is used both:
- as the name for a local variable
- as the name of a type in glibc, in file malloc/dynarray-skeleton.c, as included
by nss/nss_files/files-hosts.c.
Fix this by ignoring the shared lib symbols.
Likewise in a couple of other fortran tests.
Tested on x86_64-linux.
Andrew Burgess [Thu, 7 Oct 2021 16:50:33 +0000 (17:50 +0100)]
z80/disassembler: call memory_error_func when appropriate
If a call to the read_memory_func fails then we should call the
memory_error_func to notify the user of the disassembler of the
address that was a problem.
Without this GDB will report all memory errors as being at address
0x0.
opcodes/ChangeLog:
* z80-dis.c (fetch_data): Call memory_error_func if the
read_memory_func call fails.
Andrew Burgess [Thu, 7 Oct 2021 16:48:28 +0000 (17:48 +0100)]
s12z/disassembler: call memory_error_func when appropriate
If a call to the read_memory_func fails then we should call the
memory_error_func to notify the user of the disassembler of the
address that was a problem.
Without this GDB will report all memory errors as being at address
0x0.
opcodes/ChangeLog:
* s12z-disc.c (abstract_read_memory): Call memory_error_func if
the read_memory_func call fails.
Tom de Vries [Mon, 11 Oct 2021 11:31:54 +0000 (13:31 +0200)]
[gdb/testsuite] Fix double debug info in gdb.dwarf2/dw2-ref-missing-frame.exp
A mistake slipped in in commit
a5ea23036d8 "[gdb/testsuite] Use function_range
in gdb.dwarf2/dw2-ref-missing-frame.exp".
Before the commit the main file was compiled with debug info, and the two
others not:
...
if {[prepare_for_testing_full "failed to prepare" \
[list $testfile {} $srcfile {} $srcfuncfile {} \
$srcmainfile debug]]} {
...
After the commit, all were compiled with debug info, and consequently, there
are two versions of debug info for $srcfuncfile. This shows up as a FAIL when
running the test-case with target boards readnow and cc-with-debug-names.
Fix this by using prepare_for_testing_full, as before.
Tested on x86_64-linux.
Fixes: a5ea23036d8 ("[gdb/testsuite] Use function_range in
gdb.dwarf2/dw2-ref-missing-frame.exp")
Tom de Vries [Mon, 11 Oct 2021 10:21:00 +0000 (12:21 +0200)]
[gdb/testsuite] Use require for ensure_gdb_index
Replace:
...
if { [ensure_gdb_index $binfile] == -1 } {
return -1
}
...
with:
...
require {ensure_gdb_index $binfile} != -1
...
and consequently, add a missing UNTESTED message.
Tested on x86_64-linux, both with native and target board readnow.
Tom de Vries [Mon, 11 Oct 2021 10:21:00 +0000 (12:21 +0200)]
[gdb/testsuite] Handle readnow in ensure_gdb_index
When running test-case gdb.base/with-mf.exp with target board readnow, I run
into:
...
FAIL: gdb.base/with-mf.exp: check if index present
...
This is since commit
6010fb0c49e "[gdb/testsuite] Fix full buffer in
gdb.rust/dwindex.exp".
Before that commit, the proc ensure_gdb_index would treat the line:
...
.gdb_index: faked for "readnow"^M
...
as proof that an index is already present (which is incorrect).
Now, instead it generates aforementioned FAIL and continues to generate an
index.
Fix this by explicitly handling the readnow case in proc ensure_gdb_index,
such that we bail out instead.
Tested on x86_64-linux.
projects / binutils-gdb.git / log