Tom Tromey [Thu, 2 Jul 2020 03:21:12 +0000 (21:21 -0600)]
Use complete_on_enum in tui_reggroup_completer
tui_reggroup_completer has an "XXXX" comment suggesting the use of
complete_on_enum. This patch implements this suggestion.
gdb/ChangeLog
2020-07-01 Tom Tromey <tom@tromey.com>
* tui/tui-regs.c (tui_reggroup_completer): Use complete_on_enum.
GDB Administrator [Thu, 2 Jul 2020 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in
Fangrui Song [Wed, 1 Jul 2020 19:31:44 +0000 (12:31 -0700)]
Recognize -1 as a tombstone value in .debug_line
LLD from 11 onwards (https://reviews.llvm.org/D81784) uses -1 to
represent a relocation in .debug_line referencing a discarded symbol.
Recognize -1 to fix gdb.base/break-on-linker-gcd-function.exp when the
linker is a newer LLD.
gdb/ChangeLog:
* dwarf2/read.c (lnp_state_machine::check_line_address): Test -1.
Alan Modra [Wed, 1 Jul 2020 07:24:50 +0000 (16:54 +0930)]
PR26188, buff overflow in coff_find_nearest_line_with_names
PR 26188
* coffgen.c (coff_find_nearest_line_with_names): Sanity check
raw syment index before dereferencing.
Alok Kumar Sharma [Wed, 1 Jul 2020 06:23:09 +0000 (11:53 +0530)]
Allow reference form for DW_AT_associated and DW_AT_allocated attributes
Currently, GDB rejects the (die) reference form while it accepts exprloc
form. It is allowed in DWARF standard. "Table 7.5: Attribute encodings"
in DWARF5 standard. Flang compiler assigns (die) reference to
DW_AT_associated and DW_AT_allocated for some cases.
gdb/ChangeLog
* dwarf2/read.c (set_die_type): Removed conditions to restrict
forms for DW_AT_associated and DW_AT_allocated attributes,
which is already checked in function attr_to_dynamic_prop.
Alan Modra [Wed, 1 Jul 2020 07:22:02 +0000 (16:52 +0930)]
Re: Remove x86 NaCl target support
Fixes accidental breakage of vxworks by commit
bbd19b19e4.
* elf32-i386.c (elf_backend_object_p): Undef for vxworks.
Alan Modra [Tue, 30 Jun 2020 23:45:34 +0000 (09:15 +0930)]
obsolete xc16x
The xc16x md_apply_fix code is just so broken that in my opinion the
target should never have been accepted, and from a quick look at
commit logs for the target it appears that no one has ever contributed
fixes for anything. This target has just been a 14 year burden on
global binutils and cgen maintainers. That's not how free software is
supposed to work.
bfd/
* config.bfd: Obsolete xc16x.
gas/
* config/tc-xc16x.c (md_apply_fix): Add FIXME.
Alan Modra [Tue, 30 Jun 2020 23:44:45 +0000 (09:14 +0930)]
gas eqv-dot test fails
* testsuite/gas/all/eqv-dot.d: xfail targets that set linkrelax
in data sections, and mep.
GDB Administrator [Wed, 1 Jul 2020 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Tue, 30 Jun 2020 21:17:07 +0000 (15:17 -0600)]
Update readline/README to mention patchlevel
This updates readline/README to mention the current patchlevel, and
the "git am" approach to importing new upstream patches.
readline/ChangeLog
2020-06-30 Tom Tromey <tom@tromey.com>
* README: Update instructions.
Chet Ramey [Fri, 7 Feb 2020 19:58:55 +0000 (14:58 -0500)]
problems restoring the history file are not signaled correctly to the calling application
Chet Ramey [Fri, 7 Feb 2020 19:57:47 +0000 (14:57 -0500)]
reading history entries with timestamps can result in joined entries
Chet Ramey [Fri, 7 Feb 2020 19:56:45 +0000 (14:56 -0500)]
fix problems moving back beyond start of history
Chet Ramey [Wed, 14 Aug 2019 15:28:48 +0000 (11:28 -0400)]
Readline-8.0 patch 1: fix file descriptor leak with zero-length history file
Philippe Waroquiers [Tue, 30 Jun 2020 16:40:21 +0000 (18:40 +0200)]
Fix test breakages caused by removal of gdb_py_test_multiple.
Tom de Vries detected that some python tests were broken as
they were still using gdb_py_test_multiple that was replaced
by gdb_test_multiline. Repair these tests by using the new function.
gdb/testsuite/ChangeLog
2020-06-30 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.python/py-breakpoint.exp: use gdb_test_multiline instead
of gdb_py_test_multiple.
* gdb.python/py-cmd.exp: Likewise.
* gdb.python/py-events.exp: Likewise.
* gdb.python/py-function.exp: Likewise.
* gdb.python/py-inferior.exp: Likewise.
* gdb.python/py-infthread.exp: Likewise.
* gdb.python/py-linetable.exp: Likewise.
* gdb.python/py-parameter.exp: Likewise.
* gdb.python/py-value.exp: Likewise.
H.J. Lu [Tue, 30 Jun 2020 15:47:02 +0000 (08:47 -0700)]
Remove x86 NaCl target support
NaCl has been deprecated:
https://developer.chrome.com/native-client/migration
and NaCl will completely disappear in 2021:
https://lists.llvm.org/pipermail/llvm-dev/2020-April/141107.html
Remove x86 NaCl target support from bfd, binutils, gas and ld.
bfd/
* archures.c (bfd_mach_i386_nacl): Removed.
(bfd_mach_i386_i386_nacl): Likewise.
(bfd_mach_x86_64_nacl): Likewise.
(bfd_mach_x64_32_nacl): Likewise.
* config.bfd: Remove *-*-nacl* targets.
* configure.ac: Remove x86 NaCl target vectors.
* cpu-i386.c (bfd_arch_i386_onebyte_nop_fill): Removed.
(bfd_x64_32_nacl_arch): Likewise.
(bfd_x86_64_nacl_arch): Likewise.
(bfd_i386_nacl_arch): Likewise.
(bfd_x64_32_arch_intel_syntax): Updated.
* elf32-i386.c: Don't include "elf-nacl.h".
(elf_i386_nacl_plt): Removed.
(elf_i386_nacl_plt0_entry): Likewise.
(elf_i386_nacl_plt_entry): Likewise.
(elf_i386_nacl_pic_plt0_entry): Likewise.
(elf_i386_nacl_pic_plt_entry): Likewise.
(elf_i386_nacl_eh_frame_plt): Likewise.
(elf_i386_nacl_plt): Likewise.
(elf32_i386_nacl_elf_object_p): Likewise.
(elf_i386_get_synthetic_symtab): Updated.
(elf_i386_link_setup_gnu_properties): Likewise.
* elf64-x86-64.c: Don't include "elf-nacl.h".
(elf_x86_64_nacl_plt): Removed.
(elf64_x86_64_nacl_elf_object_p): Likewise.
(elf_x86_64_nacl_plt0_entry): Likewise.
(elf_x86_64_nacl_plt_entry): Likewise.
(elf_x86_64_nacl_eh_frame_plt): Likewise.
(elf_x86_64_nacl_plt): Likewise.
(elf32_x86_64_nacl_elf_object_p): Likewise.
(elf_x86_64_get_synthetic_symtab): Updated.
(elf_x86_64_link_setup_gnu_properties): Likewise.
* elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties): Likewise.
* targets.c: Remove x86 NaCl target vectors.
* bfd-in2.h: Regenerated.
* configure: Likewise.
binutils/
* NEWS: Mention x86 NaCl target support removal.
* dwarf.c (init_dwarf_regnames_by_bfd_arch_and_mach): Remove
x86 NaCl target support.
* testsuite/binutils-all/elfedit-1.d: Likewise.
* testsuite/binutils-all/i386/i386.exp: Likewise.
* testsuite/binutils-all/x86-64/objects.exp: Likewise.
* testsuite/binutils-all/x86-64/pr23494a-x32.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494a.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494b-x32.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494b.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494c-x32.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494c.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494d-x32.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494d.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494e-x32.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494e.d: Likewise.
* testsuite/binutils-all/x86-64/x86-64.exp: Likewise.
gas/
* NEWS: Mention x86 NaCl target support removal.
* config/tc-i386.c: Remove x86 NaCl target support.
* config/tc-i386.h: Likewise.
* configure.tgt: Likewise.
* testsuite/gas/i386/i386.exp: Likewise.
* testsuite/gas/i386/iamcu-1.d: Likewise.
* testsuite/gas/i386/iamcu-2.d: Likewise.
* testsuite/gas/i386/iamcu-3.d: Likewise.
* testsuite/gas/i386/iamcu-4.d: Likewise.
* testsuite/gas/i386/iamcu-5.d: Likewise.
* testsuite/gas/i386/k1om.d: Likewise.
* testsuite/gas/i386/l1om.d: Likewise.
ld/
* Makefile.am (ALL_EMULATION_SOURCES): Remove eelf_i386_nacl.c,
eelf32_x86_64_nacl.c, eelf_x86_64_nacl.c.
Remove x86 NaCl dep files.
* NEWS: Mention x86 NaCl target support removal.
* configure.tgt: Remove x86 NaCl target support.
* testsuite/ld-elf/binutils.exp: Likewise.
* testsuite/ld-elf/elf.exp: Likewise.
* testsuite/ld-elfvers/vers.exp: Likewise.
* testsuite/ld-i386/align-branch-1.d: Likewise.
* testsuite/ld-i386/export-class.exp: Likewise.
* testsuite/ld-i386/i386.exp: Likewise.
* testsuite/ld-i386/load1.d: Likewise.
* testsuite/ld-i386/pie1.d: Likewise.
* testsuite/ld-i386/pr12570a.d: Likewise.
* testsuite/ld-i386/pr12570b.d: Likewise.
* testsuite/ld-i386/pr19636-1d.d: Likewise.
* testsuite/ld-i386/pr19636-1l.d: Likewise.
* testsuite/ld-i386/pr19636-2c.d: Likewise.
* testsuite/ld-i386/pr19636-2d.d: Likewise.
* testsuite/ld-i386/pr19636-2e.d: Likewise.
* testsuite/ld-i386/pr20244-1a.d: Likewise.
* testsuite/ld-i386/pr20244-1b.d: Likewise.
* testsuite/ld-i386/pr20244-2a.d: Likewise.
* testsuite/ld-i386/pr20244-2b.d: Likewise.
* testsuite/ld-i386/pr20244-2c.d: Likewise.
* testsuite/ld-i386/pr20244-4a.d: Likewise.
* testsuite/ld-i386/pr20244-4b.d: Likewise.
* testsuite/ld-i386/pr21884.d: Likewise.
* testsuite/ld-ifunc/binutils.exp: Likewise.
* testsuite/ld-ifunc/ifunc-10-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-10-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-11-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-11-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-12-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-12-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-13-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-13-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-14a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-14a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-14b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-14b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-14c-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-14c-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-14d-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-14d-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-14e-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-14e-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-14f-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-14f-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-15-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-15-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-16-i386-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-16-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-16-x86-64-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-16-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-17a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-17a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-17b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-17b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-18a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-18a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-18b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-18b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-19a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-19a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-19b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-19b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-i386-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-local-i386-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-local-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-local-x86-64-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-local-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-x86-64-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-20-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-20-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-21-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-21-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-22-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-22-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-5a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-5a-local-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-5a-local-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-5a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-5b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-5b-local-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-5b-local-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-5b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-5r-local-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-5r-local-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-6a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-6a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-6b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-6b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-7a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-7a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-7b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-7b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-8-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-8-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-9-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-9-x86-64.d: Likewise.
* testsuite/ld-ifunc/pr17154-i386-now.d: Likewise.
* testsuite/ld-ifunc/pr17154-i386.d: Likewise.
* testsuite/ld-ifunc/pr17154-x86-64-now.d: Likewise.
* testsuite/ld-ifunc/pr17154-x86-64.d: Likewise.
* testsuite/ld-plugin/lto.exp: Likewise.
* testsuite/ld-x86-64/align-branch-1.d: Likewise.
* testsuite/ld-x86-64/dwarfreloc.exp: Likewise.
* testsuite/ld-x86-64/line.exp: Likewise.
* testsuite/ld-x86-64/load1a.d: Likewise.
* testsuite/ld-x86-64/load1b.d: Likewise.
* testsuite/ld-x86-64/load1c.d: Likewise.
* testsuite/ld-x86-64/load1d.d: Likewise.
* testsuite/ld-x86-64/pie3.d: Likewise.
* testsuite/ld-x86-64/pr18160.d: Likewise.
* testsuite/ld-x86-64/pr19013-x32.d: Likewise.
* testsuite/ld-x86-64/pr19013.d: Likewise.
* testsuite/ld-x86-64/pr19636-2d.d: Likewise.
* testsuite/ld-x86-64/pr19636-2l.d: Likewise.
* testsuite/ld-x86-64/pr20253-1b.d: Likewise.
* testsuite/ld-x86-64/pr20253-1d.d: Likewise.
* testsuite/ld-x86-64/pr20253-1f.d: Likewise.
* testsuite/ld-x86-64/pr20253-1h.d: Likewise.
* testsuite/ld-x86-64/pr20253-1j.d: Likewise.
* testsuite/ld-x86-64/pr20253-1l.d: Likewise.
* testsuite/ld-x86-64/pr21884.d: Likewise.
* testsuite/ld-x86-64/pr22393-3a.rd: Likewise.
* testsuite/ld-x86-64/pr22393-3b.rd: Likewise.
* testsuite/ld-x86-64/tlsgd10.dd: Likewise.
* testsuite/ld-x86-64/tlsgd5.dd: Likewise.
* testsuite/ld-x86-64/tlsgd8.dd: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* emulparams/elf32_x86_64_nacl.sh: Removed.
* emulparams/elf_i386_nacl.sh: Likewise.
* emulparams/elf_x86_64_nacl.sh: Likewise.
* testsuite/ld-i386/emit-relocs-nacl.rd: Likewise.
* testsuite/ld-i386/load1-nacl.d: Likewise.
* testsuite/ld-i386/pie1-nacl.d: Likewise.
* testsuite/ld-i386/plt-nacl.pd: Likewise.
* testsuite/ld-i386/plt-pic-nacl.pd: Likewise.
* testsuite/ld-i386/pr17709-nacl.rd: Likewise.
* testsuite/ld-i386/pr19636-1d-nacl.d: Likewise.
* testsuite/ld-i386/pr19636-2c-nacl.d: Likewise.
* testsuite/ld-i386/pr19636-2d-nacl.d: Likewise.
* testsuite/ld-i386/pr19636-2e-nacl.d: Likewise.
* testsuite/ld-i386/pr19827-nacl.rd: Likewise.
* testsuite/ld-i386/pr21884-nacl.d: Likewise.
* testsuite/ld-i386/pr21884-nacl.t: Likewise.
* testsuite/ld-i386/tlsbin-nacl.rd: Likewise.
* testsuite/ld-i386/tlsbin2-nacl.rd: Likewise.
* testsuite/ld-i386/tlsbindesc-nacl.rd: Likewise.
* testsuite/ld-i386/tlsdesc-nacl.rd: Likewise.
* testsuite/ld-i386/tlsgdesc-nacl.rd: Likewise.
* testsuite/ld-i386/tlsnopic-nacl.rd: Likewise.
* testsuite/ld-i386/tlspic-nacl.rd: Likewise.
* testsuite/ld-i386/tlspic2-nacl.rd: Likewise.
* testsuite/ld-x86-64/ilp32-4-nacl.d: Likewise.
* testsuite/ld-x86-64/load1a-nacl.d: Likewise.
* testsuite/ld-x86-64/load1b-nacl.d: Likewise.
* testsuite/ld-x86-64/load1c-nacl.d: Likewise.
* testsuite/ld-x86-64/load1d-nacl.d: Likewise.
* testsuite/ld-x86-64/pie3-nacl.d: Likewise.
* testsuite/ld-x86-64/plt-nacl.pd: Likewise.
* testsuite/ld-x86-64/pr17709-nacl.rd: Likewise.
* testsuite/ld-x86-64/pr19013-nacl.d: Likewise.
* testsuite/ld-x86-64/pr19636-2d-nacl.d: Likewise.
* testsuite/ld-x86-64/pr19827-nacl.rd: Likewise.
* testsuite/ld-x86-64/pr21884-nacl.d: Likewise.
* testsuite/ld-x86-64/pr21884-nacl.t: Likewise.
* testsuite/ld-x86-64/split-by-file-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlsbin-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlsbin2-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlsbindesc-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlsdesc-nacl.pd: Likewise.
* testsuite/ld-x86-64/tlsdesc-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlsgdesc-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlspic-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlspic2-nacl.rd: Likewise.
* Makefile.in: Regenerated.
* po/BLD-POTFILES.in: Likewise.
Tom Tromey [Tue, 30 Jun 2020 13:57:35 +0000 (07:57 -0600)]
Fix bug in quirk_rust_enum
Tom de Vries pointed out that some Rust tests were failing after the
variant part rewrite. He sent an executable, which helped track down
this bug.
quirk_rust_enum was passing 1 to alloc_rust_variant in one case.
However, a comment earlier says:
/* We don't need a range entry for the discriminant, but we do
need one for every other field, as there is no default
variant. */
In this case, we must pass -1 for this parameter. That is what this
patch implements.
gdb/ChangeLog
2020-06-30 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (quirk_rust_enum): Correctly call
alloc_rust_variant for default-less enum.
Tom Tromey [Tue, 30 Jun 2020 13:53:03 +0000 (07:53 -0600)]
Do not define basic_string_view::to_string
gdb's copy of basic_string_view includes a to_string method. However,
according to cppreference, this is not a method on the real
std::basic_string_view:
https://en.cppreference.com/w/cpp/string/basic_string_view
This difference matters because gdb_string_view.h will use the
standard implementation when built with a C++17 or later. This caused
PR build/26183.
This patch fixes the problem by changing the method to be a standalone
helper function, and then rewriting the uses. Tested by rebuilding
with a version of GCC that defaults to C++17.
(Note that the build still is not clean; and also I noticed that the
libstdc++ string_view forbids the use of nullptr ... I wonder if gdb
violates that.)
gdb/ChangeLog
2020-06-30 Tom Tromey <tromey@adacore.com>
PR build/26183:
* ada-lang.c (ada_lookup_name_info::ada_lookup_name_info): Use
gdb::to_string.
gdbsupport/ChangeLog
2020-06-30 Tom Tromey <tromey@adacore.com>
PR build/26183:
* gdb_string_view.h (basic_string_view::to_string): Remove.
(gdb::to_string): New function.
Nick Clifton [Tue, 30 Jun 2020 12:05:18 +0000 (13:05 +0100)]
Add support for attributes using DW_FORM_GNU_strp_alt
* dwarf.c (read_and_display_attr_value): Support
DW_FORM_GNU_strp_alt when used with DW_AT_dwo_name and
DW_AT_comp_dir.
Tom de Vries [Tue, 30 Jun 2020 07:23:09 +0000 (09:23 +0200)]
[gdb/testsuite] Handle early_flags in gdb_default_target_compile
In gdb_default_target_compile, we use dejagnu's default_target_compile, unless
we need support for languages that are not yet support in the used dejagnu
version, in which case we use a local default_target_compile:
gdb_default_target_compile_1.
However, there's another reason to use the local default_target_compile: when
early_flags is used, because there's no dejagnu release available yet
supporting this.
Fix this by detecting and handling early_flags in gdb_default_target_compile.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-30 Tom de Vries <tdevries@suse.de>
PR testsuite/26175
* lib/future.exp (gdb_default_target_compile): Detect and handle
early_flags.
Alan Modra [Tue, 30 Jun 2020 04:42:49 +0000 (14:12 +0930)]
solaris XPASS ld-elf/group1
* testsuite/ld-elf/group1.d: Don't xfail all solaris targets, just
ix86 and x86_64.
Alan Modra [Tue, 30 Jun 2020 04:17:32 +0000 (13:47 +0930)]
Don't xfail nds32 for ld-elf/reloc-discard test
* testsuite/ld-elf/reloc-discard.d: Don't xfail nds32.
Alan Modra [Tue, 30 Jun 2020 03:45:29 +0000 (13:15 +0930)]
Fix nds32*-elf XPASS readelf -wiaoRlL dw5
The underlying fail was probably fixed with git commit
fbaf61ad5.
* testsuite/binutils-all/readelf.exp (readelf_dump_test): Remove
xfail for nds32.
Alan Modra [Tue, 30 Jun 2020 03:52:52 +0000 (13:22 +0930)]
microblaze-linux XPASS ld-elf/var1
microblaze-linux uses the standard ELF script, microblaze-elf its own
script lacking an input section pattern needed to make this test pass.
Add the missing pattern for .data, in line with most other sections
that do have .* patterns.
* scripttempl/elfmicroblaze.sc (.data): Add .data.* entry.
* testsuite/ld-elf/var1.d: Don't xfail microblaze.
Nelson Chu [Mon, 8 Jun 2020 02:54:53 +0000 (10:54 +0800)]
RISC-V: Support debug and float CSR as the unprivileged ones.
The unprivileged CSR should be controlled by other specific specs rather
than the privileged spec. For example, the debug CSR should be controlled
by the debug spec, and the float CSR should be controlled by the float
spec. User may use assembler options to choose what the debug and other
specs they want, or may encode the versions of specs into the architecture
string directly. Since we haven't decided which one is better, we set the
defined and aborted versions of unprivileged CSR to PRIV_SPEC_CLASS_NONE
in the include/opcode/riscv-opc.h, to tell assembler don't check priv spec
versions for them. However, these PRIV_SPEC_CLASS_NONE will be changed
to FLOAT_SPEC_CLASS_* and DEBUG_SPEC_CLASS_* in the future.
gas/
* config/tc-riscv.c (riscv_csr_class_check): Removed. Move the
checking into riscv_csr_address.
(riscv_csr_version_check): Likewise.
(riscv_csr_address): New function. Return the suitable CSR address
after checking the ISA dependency and versions. Issue warnings if
we find any conflict and -mcsr-check is set. CSR_CLASS_F and
CSR_CLASS_DEBUG are unprivileged CSR for now, so don't check the
priv spec versions for them.
(reg_csr_lookup_internal): Call riscv_csr_address to find the
suitable CSR address.
* testsuite/gas/riscv/priv-reg-fail-fext.d: Remove -mpriv-spec=1.11.
* testsuite/gas/riscv/priv-reg-fail-read-only-01.d: Likewise.
* testsuite/gas/riscv/priv-reg-fail-rv32-only.d: Likewise.
* testsuite/gas/riscv/priv-reg-fail-fext.l: We don't care the
priv spec warnings here. These warnings are added by accident.
Remove them and only focus on the ISA dependency warnings.
* testsuite/gas/riscv/priv-reg-fail-rv32-only.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-read-only-01.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p9.l: Updated since
dscratch0 and dscratch1 are regarded as the unprivileged CSR rather
than the privileged ones.
* testsuite/gas/riscv/priv-reg-fail-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p10.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p11.l: Likewise.
* testsuite/gas/riscv/priv-reg.s: Likewise. Add missing debug CSR.
* testsuite/gas/riscv/priv-reg-version-1p9.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p10.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
include/
* opcode/riscv-opc.h: Support the unprivileged CSR. The versions
of the unprivileged CSR should be PRIV_SPEC_CLASS_NONE for now.
* opcode/riscv.h (enum riscv_csr_class): Add CSR_CLASS_DEBUG.
opcodes/
* riscv-dis.c (print_insn_args, case 'E'): Updated. Let the
unprivileged CSR can also be initialized.
Nelson Chu [Tue, 23 Jun 2020 06:23:51 +0000 (14:23 +0800)]
RISC-V: Cleanup the include/opcode/riscv-opc.h.
The include/opcode/riscv-opc.h file is no longer automatically generated,
so we remove the misleading comments and add new ones. Besides, the CAUSE_*
macros and DECLARE_CAUSE are unused for binutils and gdb. Therefore, remove
them, too.
include/
* opcode/riscv-opc.h: Cleanup and remove the unused macros.
GDB Administrator [Tue, 30 Jun 2020 00:00:08 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Mon, 29 Jun 2020 15:27:40 +0000 (11:27 -0400)]
gdb: fix documentation of gdbarch_displaced_step_copy_insn
I spotted something that looks wrong in the doc of
gdbarch_displaced_step_copy_insn.
It says that if the function returns NULL, it means that it has emulated
the behavior of the instruction and written the result to REGS.
However, it says below that the function may return NULL to indicate
that the instruction can't be single-stepped out-of-line, in which case
the core steps the instruction in-line. The two are contradictory.
The right one is the latter, if the function returns NULL, the core
falls back to in-line stepping. I checked all the implementations of
this function and they all agree with this.
gdb/ChangeLog:
* gdbarch.sh (displaced_step_copy_insn): Update doc.
* gdbarch.h: Re-generate.
Change-Id: I98163cdd38970cde4c77680e249b10f5d2d5bf9b
Simon Marchi [Mon, 29 Jun 2020 14:19:43 +0000 (10:19 -0400)]
gdb/testsuite: better handle failures in simavr board, reap simavr process
This patch makes a few adjustments to the simavr.exp to handle tests
that error out more gracefully. I put all the changes in the same patch
because right now it's in a very bad shape, so it's very painful to do
small incremental adjustements. I found that with these changes, it
becomes reasonably stable.
For example, the gdb.base/step-over-syscall.exp test is a bit buggy
(stuff for another patch...), in that it calls gdb_load (through
clean_restart) with a file that doesn't exist. The gdb_load
implementation in simavr.exp gets called with a file that doesn't exist,
and simavr (expectedly) fails to start.
When this happens, we currently leave the $simavr_spawn_id variable set.
However, because the simavr process has terminated, its spawn id is
closed. When the next test tries to close the previous connection to
simavr, it fails to, and this error is thrown:
ERROR: close: spawn id exp86 not open
while executing
"close -i $simavr_spawn_id"
(procedure "gdb_load" line 18)
invoked from within
In other words, any test ran after step-over-syscall.exp will have
simavr.exp's gdb_load fail on it.
This patch tries to make sure that simavr.exp's gdb_load only leaves
simavr_spawn_id set if everything went fine. If we couldn't start
simavr, don't see the expected output, or fail to connect to it, we
close the spawn id (if needed) and unset simavr_spawn_id.
As an additional precaution, I added a catch around the "close the
previous connection" code. Ideally, this shouldn't be necessary, but I
bet there are other similar scenarios where we might try to close an
already close spawn id. So I think displaying a warning is better than
messing up all following tests.
Also, the board never wait'ed for the simavr process, resulting in tons
of zombie simavr processes hanging around. This patch adds some calls
to "wait" whenever we close the connection (or realize it is already
closed), which seems to fix the problem.
Finally I switched a `gdb_expect` to bare `expect`, where we wait for
the "listening" message from simavr. I found it necessary because
gdb_expect (through remote_expect) adds a `-i <gdb spawn id> -timeout
10`. So if for some reason the GDB process has crashed in the mean
time, this expect will unexpectedly error out with a `spawn id <gdb
spawn id> not open`. Therefore, change `gdb_expect` to `expect` so that
we only deal with simavr's spawn id here.
Here are the results on TESTS="gdb.base/*.exp" before:
# of expected passes 4816
# of unexpected failures 4433
# of known failures 2
# of unresolved testcases 300
# of untested testcases 143
# of unsupported tests 7
# of paths in test names 2
# of duplicate test names 10
and after:
# of expected passes 21957
# of unexpected failures 1564
# of expected failures 8
# of unknown successes 1
# of known failures 31
# of unresolved testcases 532
# of untested testcases 153
# of unsupported tests 28
# of paths in test names 2
# of duplicate test names 32
I tested using simavr's current master (
7c254e2081b5).
gdb/testsuite/ChangeLog:
* boards/simavr.exp (gdb_load): Catch errors when closing
previous connection. Close connection, wait for process and
unset simavr_spawn_id on failure.
Change-Id: I695fc765e1c22e1d1dc0b08e0f5141244986b868
H.J. Lu [Mon, 29 Jun 2020 13:28:31 +0000 (06:28 -0700)]
x86: Support VEX base opcode length > 1
Intel AMX instructions with 8-bit immediate opcode extension without
operands:
tilerelease, 0, 0x49c0, None, 2, CpuAMX_TILE|Cpu64, Vex|VexOpcode=1|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }
Update build_vex_prefix to support VEX base opcode length > 1.
* tc-i386.c (build_vex_prefix): Support VEX base opcode length > 1.
(md_assemble): Don't process ImmExt without operands.
H.J. Lu [Mon, 29 Jun 2020 12:52:22 +0000 (05:52 -0700)]
tic6x: Call _bfd_elf_add_dynamic_tags
Update tic6x linker tests to expect C6000_DSBT_BASE, C6000_DSBT_SIZE and
C6000_DSBT_INDEX dynamic tags immediately before NULL dynamic tag.
bfd/
* elf32-tic6x.c (elf32_tic6x_size_dynamic_sections): Call
_bfd_elf_add_dynamic_tags.
ld/
* testsuite/ld-tic6x/shlib-1.rd: Move C6000_DSBT_BASE,
C6000_DSBT_SIZE and C6000_DSBT_INDEX dynamic tags to the last.
* testsuite/ld-tic6x/shlib-1b.rd: Likewise.
* testsuite/ld-tic6x/shlib-1r.rd: Likewise.
* testsuite/ld-tic6x/shlib-1rb.rd: Likewise.
* testsuite/ld-tic6x/shlib-app-1.rd: Likewise.
* testsuite/ld-tic6x/shlib-app-1b.rd: Likewise.
* testsuite/ld-tic6x/shlib-app-1r.rd: Likewise.
* testsuite/ld-tic6x/shlib-app-1rb.rd: Likewise.
* testsuite/ld-tic6x/shlib-noindex.rd: Likewise.
* testsuite/ld-tic6x/static-app-1.rd: Likewise.
* testsuite/ld-tic6x/static-app-1b.rd: Likewise.
* testsuite/ld-tic6x/static-app-1r.rd: Likewise.
* testsuite/ld-tic6x/static-app-1rb.rd: Likewise.
Tom de Vries [Mon, 29 Jun 2020 11:59:19 +0000 (13:59 +0200)]
[gdb/testsuite] Emit unresolved for unknown proc
Since commit
26783bce15 "[gdb/testsuite] Don't abort testrun for invalid
command in test-case" we don't abort the testrun when encountering an invalid
command. However, since we don't report errors in the summary, there's a
chance that the error goes unnoticed.
Make the invalid command error more visible by marking the test-case
unresolved, such that we have f.i.:
...
PASS: gdb.python/py-breakpoint.exp: test_bkpt_internal: Test watchpoint write
UNRESOLVED: gdb.python/py-breakpoint.exp: test_bkpt_eval_funcs: \
testcase aborted due to invalid command name: gdb_py_test_multiple
ERROR: tcl error sourcing py-breakpoint.exp.
ERROR: invalid command name "gdb_py_test_multiple"
while executing
...
=== gdb Summary ===
nr of expected passes 56
nr of unresolved testcases 1
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-29 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (unknown): Make test-case unresolved.
Tom de Vries [Mon, 29 Jun 2020 10:14:10 +0000 (12:14 +0200)]
[gdbserver] Add missing include of gdbsupport/agent.h
The file gdbserver/ax.h contains:
...
#ifdef IN_PROCESS_AGENT
#define debug_threads debug_agent
#endif
...
but does not declare debug_agent.
Fix this by adding an include of gdbsupport/agent.h.
[ If this fix would have been in place before commit
8118159c69 "[gdbserver] Fix
Wlto-type-mismatch for debug_agent", we would have simply run into this build
breaker with a regular, non-lto build:
...
src/gdbserver/ax.cc:28:5: error: conflicting declaration 'int debug_agent'
int debug_agent = 0;
^~~~~~~~~~~
In file included from src/gdbserver/ax.h:25:0,
from src/gdbserver/ax.cc:20:
src/gdbsupport/agent.h:47:13: note: previous declaration as 'bool debug_agent'
extern bool debug_agent;
^~~~~~~~~~~
... ]
Tested on x86_64-linux.
gdbserver/ChangeLog:
2020-06-29 Tom de Vries <tdevries@suse.de>
* ax.h: Include gdbsupport/debug_agent.h.
Tom de Vries [Mon, 29 Jun 2020 09:02:06 +0000 (11:02 +0200)]
[gdb/testsuite] Expect conformation question in gdb.server/solib-list.exp
Before commit
a8654e7d78 'Fixes PR 25475: ensure exec-file-mismatch "ask"
always asks in case of mismatch', there was a difference in behaviour in
test-case gdb.server/solib-list.exp.
If the executable did not contain debug info (as is usually the case), gdb
would detect a mismatch but not ask for confirmation:
...
(gdb) target remote localhost:2346^M
Remote debugging using localhost:2346^M
warning: Mismatch between current exec-file solib-list^M
and automatically determined exec-file /lib64/ld-2.26.so^M
exec-file-mismatch handling is currently "ask"^M
Reading symbols from /lib64/ld-2.26.so...^M
Reading symbols from /usr/lib/debug/lib64/ld-2.26.so.debug...^M
0x00007ffff7dd7ea0 in _start () at rtld.c:745^M
745 }^M
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: target remote
...
If the executable did contain debug info (as happens to be the case for
openSUSE), gdb would detect a mismatch and ask for confirmation:
...
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: file binfile
target remote localhost:2346^M
Remote debugging using localhost:2346^M
warning: Mismatch between current exec-file solib-list^M
and automatically determined exec-file /lib64/ld-2.26.so^M
exec-file-mismatch handling is currently "ask"^M
Load new symbol table from "/lib64/ld-2.26.so"? (y or n) y^M
Reading symbols from /lib64/ld-2.26.so...^M
Reading symbols from /usr/lib/debug/lib64/ld-2.26.so.debug...^M
0x00007ffff7dd7ea0 in _start () at rtld.c:745^M
745 }^M
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: target remote
...
After commit
a8654e7d78, the confirmation is now also asked in case there's
no debug info.
Tighten the test-case by verifying that the confirmation question is asked, as
suggested in the log message of commit
a8654e7d78:
...
we can remove the bypass introduced by Tom in
6b9374f1, in order to always
answer to the 'load' question.
...
gdb/testsuite/ChangeLog:
2020-06-29 Tom de Vries <tdevries@suse.de>
PR gdb/25475
* gdb.server/solib-list.exp: Verify that the symbol reload
confirmation question is asked.
Hans-Peter Nilsson [Mon, 29 Jun 2020 03:38:26 +0000 (05:38 +0200)]
gas/testsuite: test-case for PR25331 (mmix reloc fixup bug)
The bug manifested "only" for a 64-bit host:
pr25331.c: Assembler messages:
pr25331.c:430: Error: internal error: fixup not contained within frag
failed with: <pr25331.c: Assembler messages:
pr25331.c:430: Error: internal error: fixup not contained within frag>, no expected output
FAIL: gas/mmix/pr25331
gas:
PR gas/25331
* testsuite/gas/mmix/pr25331.d, testsuite/gas/mmix/pr25331.s: New test.
Hans-Peter Nilsson [Mon, 29 Jun 2020 03:32:02 +0000 (05:32 +0200)]
gas: Fix mmix fixups and TC_FX_SIZE_SLACK, PR25331
Finally; sorry for the delay. There were a few false starts, where I
misinterpreted the error-messages and the comment that Alan added:
it's not the fix size that's too large (and the frag too small), it's
stating the wrong size of what will be "fixed up" - that of the actual
target value, not the size of the field that needs to be adjusted.
Comments added for clarity.
Test-suite committed separately.
gas:
PR gas/25331
* config/tc-mmix.c (md_assemble) <fixup for
BFD_RELOC_MMIX_BASE_PLUS_OFFSET>: This fixup affects 1 byte, not 8.
Also, set its fx_no_overflow.
(md_convert_frag) <case ENCODE_RELAX (STATE_PUSHJSTUB, STATE_ZERO)>:
Similarly this fixup affects 4 bytes, not 8 and needs its
fx_no_overflow set.
* config/tc-mmix.h (TC_FX_SIZE_SLACK): Don't define.
Hans-Peter Nilsson [Mon, 29 Jun 2020 01:50:45 +0000 (03:50 +0200)]
binutils/dwarf.c: Correct an `index' global shadowing error for pre-4.8 GCC
In older gcc, shadowing a function name with a local variable name is
flagged as an error, certainly a bug but which is usually worked
around in binutils:
gcc -DHAVE_CONFIG_H -I. -I$SRC/binutils -I. -I$SRC/binutils -I../bfd -I$SRC/binutils/../bfd -I$SRC/binutils/../include -DLOCALEDIR="\"/usr/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -I$SRC/binutils/../zlib -g -O2 -MT dwarf.o -MD -MP -MF $depbase.Tpo -c -o dwarf.o $SRC/binutils/dwarf.c &&\
mv -f $depbase.Tpo $depbase.Po
cc1: warnings being treated as errors
$SRC/binutils/dwarf.c: In function 'display_debug_str_offsets':
$SRC/binutils/dwarf.c:6913: error: declaration of 'index' shadows a global declaration
/usr/include/string.h:309: error: shadowed declaration is here
make[4]: *** [dwarf.o] Error 1
See also GCC PR c/53066. This is just another one that crept in since
I and others last had to use an old version. The name "idx" was used
in the preceding function, display_debug_addr. Also, it was declared
c99 style (after a statement in the block). Committed as obvious.
binutils:
* dwarf.c (display_debug_str_offsets): Rename local variable
index to idx. Move to top of function.
Alan Modra [Mon, 29 Jun 2020 00:21:07 +0000 (09:51 +0930)]
asan: _bfd_pei_slurp_codeview_record use of uninit value
Fixes some seriously careless code. bfd_bread return value is
(bfd_size_type)-1 on error. "if (bfd_bread (...) < 4)" does not check
for an error since bfd_size_type is unsigned. In any case, I think we
should be reading and checking the requested length.
* peXXigen.c (_bfd_XXi_slurp_codeview_record): Properly check
return value of bfd_bread. Don't read more than requested length.
Sanity check length. Properly terminate file name.
Alan Modra [Mon, 29 Jun 2020 00:37:56 +0000 (10:07 +0930)]
C++ comments
binutils isn't c99 (yet). This replaces or removes some C++ style
comments.
bfd/
* arc-got.h: Use C style comments.
* coff-z80.c: Likewise.
* elf32-csky.c: Likewise.
* peXXigen.c: Likewise.
* elf32-m32c.c (m32c_elf_relax_delete_bytes): Remove commented out
code.
binutils/
* dwarf.c: Use C style comments.
* resrc.c: Likewise.
gas/
* config/tc-s12z.c: Use C style comments.
* config/tc-z80.c: Likewise.
* config/tc-xtensa.c (emit_ld_r_n): Remove commented out code.
include/
* coff/internal.h: Use C style comments.
* coff/pe.h: Likewise.
* elf/ppc64.h: Likewise.
opcodes/
* arm-dis.c: Use C style comments.
* cr16-opc.c: Likewise.
* ft32-dis.c: Likewise.
* moxie-opc.c: Likewise.
* tic54x-dis.c: Likewise.
* s12z-opc.c: Remove useless comment.
* xgate-dis.c: Likewise.
Alan Modra [Mon, 29 Jun 2020 00:34:11 +0000 (10:04 +0930)]
x86_64 k1om tests
On x86_64-nacl we currently see
FAIL: Absolute non-overflowing relocs
FAIL: ld-x86-64/protected2-k1om
FAIL: ld-x86-64/protected3-k1om
This limits the tests as per the l1om variants.
* testsuite/ld-x86-64/abs-k1om.d: Run only on x86_64-*-linux*.
* testsuite/ld-x86-64/protected2-k1om.d: Likewise.
* testsuite/ld-x86-64/protected3-k1om.d: Likewise.
GDB Administrator [Mon, 29 Jun 2020 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Sun, 28 Jun 2020 16:33:06 +0000 (10:33 -0600)]
Remove "cmd_type" function
The cmd_type function only has a single caller, which is in the CLI
implementation code. This patch removes the function, and moves the
cmd_types enum definition from command.h to cli-decode.h, fixing an 18
year old FIXME.
gdb/ChangeLog
2020-06-28 Tom Tromey <tom@tromey.com>
* command.h (cmd_types): Remove.
(cmd_type): Don't declare.
* cli/cli-decode.h (enum cmd_types): Uncomment. No longer a
typedef.
* cli/cli-cmds.c (setting_cmd): Use cmd->type directly.
* cli/cli-decode.c (cmd_type): Remove.
GDB Administrator [Sun, 28 Jun 2020 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Sat, 27 Jun 2020 18:38:43 +0000 (14:38 -0400)]
gdbsupport: add format attribute to print_xml_feature::add_line
Fixes this clang error:
CXX tdesc.o
/home/smarchi/src/binutils-gdb/gdbsupport/tdesc.cc:444:25: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
string_vappendf (tmp, fmt, ap);
^~~
There is already a but about GCC not emitting this warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82206
gdbsupport/ChangeLog:
* tdesc.h (class print_xml_feature) <add_line>: Add
ATTRIBUTE_PRINTF.
Change-Id: I7014075e83717f6d7e19d044a3675ff9981ebe17
Pedro Alves [Sat, 27 Jun 2020 13:56:05 +0000 (14:56 +0100)]
Make {get,set}_inferior_io_terminal inferior methods
This converts the get_inferior_io_terminal and
set_inferior_io_terminal free functions to inferior methods.
Since the related commands are called "tty", "{set,show}
inferior-tty", and MI's "-inferior-tty-{set,show}", to make the
connection between the commands and the code more obvious, the methods
are named set_tty/tty instead of set_io_terminal/io_terminal.
gdb/ChangeLog:
* fork-child.c (prefork_hook): Adjust.
* infcmd.c (set_inferior_io_terminal, get_inferior_io_terminal):
Delete.
(set_inferior_tty_command, show_inferior_tty_command): Adjust.
* inferior.c (inferior::set_tty, inferior::tty): New methods.
* inferior.h (set_inferior_io_terminal, get_inferior_io_terminal):
Remove declarations.
(struct inferior) <set_tty, tty>: New methods.
(struct inferior) <terminal>: Rename to ...
(struct inferior) <m_terminal>: ... this and make private.
* main.c (captured_main_1): Adjust.
* mi/mi-cmd-env.c (mi_cmd_inferior_tty_set): Adjust.
(mi_cmd_inferior_tty_show): Adjust.
* nto-procfs.c (nto_procfs_target::create_inferior): Adjust.
* windows-nat.c (windows_nat_target::create_inferior): Adjust.
Alan Modra [Sat, 27 Jun 2020 03:17:45 +0000 (12:47 +0930)]
asan: readelf: use after free in process_archive
This tidies up in cases where fuzzed thin archives hit the error return
path in setup_nested_archive.
* elfcomm.c (setup_nested_archive): Set nested_arch->file to NULL
after freeing.
(release_archive): Set fields of arch to NULL after freeing.
GDB Administrator [Sat, 27 Jun 2020 00:00:06 +0000 (00:00 +0000)]
Automatic date update in version.in
Philippe Waroquiers [Mon, 22 Jun 2020 19:56:59 +0000 (21:56 +0200)]
Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
H.J. Lu [Fri, 26 Jun 2020 17:24:59 +0000 (10:24 -0700)]
x86: Process ImmExt without operands
To support Intel AMX instructions with 8-bit immediate opcode extension,
but without operands:
tilerelease, 0, 0x49, 0xc0, 1, CpuAMX_TILE|Cpu64, Vex|VexOpcode=1|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ImmExt, { 0 }
process ImmExt without operands.
* config/tc-i386.c (md_assemble): Process ImmExt without
operands.
H.J. Lu [Fri, 26 Jun 2020 16:24:19 +0000 (09:24 -0700)]
i386-opc.tbl: Add a blank line
* i386-opc.tbl: Add a blank line.
H.J. Lu [Fri, 26 Jun 2020 16:20:28 +0000 (09:20 -0700)]
x86: Correct VexSIB128 to VecSIB128
H.J. Lu [Fri, 26 Jun 2020 15:24:30 +0000 (08:24 -0700)]
x86: Rename VecSIB to SIB for Intel AMX
Rename VecSIB to SIB to support Intel Advanced Matrix Extensions which
introduces instructions with a mandatory SIB byte which isn't a vector
SIB (VSIB).
gas/
* config/tc-i386.c (check_VecOperands): Replace vecsib with sib.
Replace VecSIB128, VecSIB256 and VecSIB512 with VECSIB128,
VECSIB256 and VECSIB512, respectively.
(build_modrm_byte): Replace vecsib with sib.
opcodes/
* i386-gen.c (opcode_modifiers): Replace VecSIB with SIB.
(VecSIB128): Renamed to ...
(VECSIB128): This.
(VecSIB256): Renamed to ...
(VECSIB256): This.
(VecSIB512): Renamed to ...
(VECSIB512): This.
(VecSIB): Renamed to ...
(SIB): This.
(i386_opcode_modifier): Replace vecsib with sib.
* i386-opc.tbl (VexSIB128): New.
(VecSIB256): Likewise.
(VecSIB512): Likewise.
Replace VecSIB=1, VecSIB=2 and VecSIB=3 with VexSIB128, VecSIB256
and VecSIB512, respectively.
Nick Alcock [Mon, 16 Dec 2019 14:17:26 +0000 (14:17 +0000)]
libctf: support platforms with separate libintl
We were not using the right configure machinery to spot libintl on
platforms where it was required, leading to the spurious failure of
various configure tests (e.g. for things like ELF support in BFD).
libctf/
* aclocal.m4: Add config/gettext-sister.m4: Shuffle into
alphabetical order.
* configure.ac: Add ZW_GNU_GETTEXT_SISTER_DIR.
* config.h.in: Regenerated.
* Makefile.in: Likewise.
* configure: Likewise.
Nick Alcock [Mon, 16 Dec 2019 11:38:57 +0000 (11:38 +0000)]
libctf: add some missing #includes.
Causes warnings on (at least) recent FreeBSD.
libctf/
* ctf-create.c: Include <unistd.h>.
* ctf-open-bfd.c: Likewise.
Nick Alcock [Fri, 13 Dec 2019 15:19:17 +0000 (15:19 +0000)]
libctf, elfcpp, gold: do not assume that <byteswap.h> contains bswap_*
At least one C library (uclibc-ng) defines some of these only when
the compiler is GCC. We might as well test for all three cases and
handle any of them being missing.
Very similar code exists in libctf and split between elfcpp and gold:
fix both.
(Also sync up elfcpp with a change made to libctf swap.h a few months
ago: since there is no out-of-line definition of the bswap replacements,
they should be declared static inline, not just inline, to prevent the
linker generating out-of-line references to them.)
PR libctf/25120
libctf/
* configure.ac: Check for bswap_16, bswap_32, and bswap_64 decls.
* swap.h (bswap_16): Do not assume that presence of <byteswap.h>
means this is declared.
(bswap_32): Likewise.
(bswap_64): Likewise.
(bswap_identity_64): Remove, unused.
* configure: Regenerated.
* config.h.in: Likewise.
gold/
* configure.ac: Check for bswap_16, bswap_32, and bswap_64 decls.
* configure: Regenerated.
* config.h.in: Likewise.
elfcpp/
* elfcpp_swap.h (bswap_16): Do not assume that presence of
<byteswap.h> means this is declared. Make static inline, matching
recent change to libctf, since there is no non-inline definition
of these functions.
(bswap_32): Likewise.
(bswap_64): Likewise.
Nick Alcock [Fri, 13 Dec 2019 14:54:09 +0000 (14:54 +0000)]
libctf: work with compilers not supporting GNU C attributes
The obvious fallback __attribute__ stanza was missing.
Thanks to Harald van Dijk.
PR 25120
libctf/
* ctf-impl.h (_libctf_printflike_): Add non-GNU-C fallback.
(_libctf_unlikely_): Likewise.
(_libctf_unused): Likewise.
(_libctf_malloc_): Likewise.
Nick Alcock [Fri, 13 Dec 2019 14:48:07 +0000 (14:48 +0000)]
libctf: avoid nonportable __thread in CTF archive handling
This keeps archive searching threadsafe using the new bsearch_r that was
just added to libiberty.
PR25120
libctf/
* ctf-archive.c (search_nametbl): No longer global: declare...
(ctf_arc_open_by_name_internal): ... here. Use bsearch_r.
(search_modent_by_name): Take and use ARG for the nametbl.
Nick Alcock [Fri, 13 Dec 2019 12:01:12 +0000 (12:01 +0000)]
libctf, binutils: support CTF archives like objdump
objdump and readelf have one major CTF-related behavioural difference:
objdump can read .ctf sections that contain CTF archives and extract and
dump their members, while readelf cannot. Since the linker often emits
CTF archives, this means that readelf intermittently and (from the
user's perspective) randomly fails to read CTF in files that ld emits,
with a confusing error message wrongly claiming that the CTF content is
corrupt. This is purely because the archive-opening code in libctf was
needlessly tangled up with the BFD code, so readelf couldn't use it.
Here, we disentangle it, moving ctf_new_archive_internal from
ctf-open-bfd.c into ctf-archive.c and merging it with the helper
function in ctf-archive.c it was already using. We add a new public API
function ctf_arc_bufopen, that looks very like ctf_bufopen but returns
an archive given suitable section data rather than a ctf_file_t: the
archive is a ctf_archive_t, so it can be called on raw CTF dictionaries
(with no archive present) and will return a single-member synthetic
"archive".
There is a tiny lifetime tweak here: before now, the archive code could
assume that the symbol section in the ctf_archive_internal wrapper
structure was always owned by BFD if it was present and should always be
freed: now, the caller can pass one in via ctf_arc_bufopen, wihch has
the usual lifetime rules for such sections (caller frees): so we add an
extra field to track whether this is an internal call from ctf-open-bfd,
in which case we still free the symbol section.
include/
* ctf-api.h (ctf_arc_bufopen): New.
libctf/
* ctf-impl.h (ctf_new_archive_internal): Declare.
(ctf_arc_bufopen): Remove.
(ctf_archive_internal) <ctfi_free_symsect>: New.
* ctf-archive.c (ctf_arc_close): Use it.
(ctf_arc_bufopen): Fuse into...
(ctf_new_archive_internal): ... this, moved across from...
* ctf-open-bfd.c: ... here.
(ctf_bfdopen_ctfsect): Use ctf_arc_bufopen.
* libctf.ver: Add it.
binutils/
* readelf.c (dump_section_as_ctf): Support .ctf archives using
ctf_arc_bufopen. Automatically load the .ctf member of such
archives as the parent of all other members, unless specifically
overridden via --ctf-parent. Split out dumping code into...
(dump_ctf_archive_member): ... here, as in objdump, and call
it once per archive member.
(dump_ctf_indent_lines): Code style fix.
Nick Alcock [Tue, 5 Nov 2019 17:57:55 +0000 (17:57 +0000)]
libctf: create: forwards are always in the namespace of their referent
The C namespace a forward is located in is always the same as the
namespace of the corresponding complete type: 'struct foo' is in the
struct namespace and does not collide with, say, 'union foo'.
libctf allowed for this in many places, but inconsistently: in
particular, forward *addition* never allowed for this, and was interning
forwards in the default namespace, which is always wrong, since you can
only forward structs, unions and enums, all of which are in their own
namespaces in C.
Forward removal needs corresponding adjustment to remove the names form
the right namespace, as does ctf_rollback.
libctf/
* ctf-create.c (ctf_add_forward): Intern in the right namespace.
(ctf_dtd_delete): Remove correspondingly.
(ctf_rollback): Likewise.
Nick Alcock [Tue, 5 Nov 2019 13:09:57 +0000 (13:09 +0000)]
libctf: create: ctf_add_type should hand back already-added non-SoUs
When we add a type from a dictionary and then try to add it again, we
should hand it back unchanged unless it is a structure, union or enum
with a different number of members. That's what the comment says we do.
Instead, we hand it back unchanged *only* if it is a structure, union or
enum with the same number of members: non-structs, unions and enums are
unconditionally added. This causes extreme type bloating and (in
conjunction with the bug fixed by the next commit) can easily lead to
the same type being mistakenly added to a dictionary more than once
(which, for forwards, was not banned and led to dictionary corruption).
libctf/
* ctf-create.c (ctf_add_type_internal): Hand back existing types
unchanged.
Nick Alcock [Mon, 21 Oct 2019 10:33:19 +0000 (11:33 +0100)]
libctf: create: don't add forwards if the type added already exists
This is what ctf_add_forward is documented to do, but it's not what it
actually does: the code is quite happy to add forwards that duplicate
existing structs, etc.
This is obviously wrong and breaks both the nondeduplicating linker
and the upcoming deduplicator, as well as allowing ordinary callers of
ctf_add_type to corrupt the dictionary by just adding the same root-
visible forward more than once.
libctf/
* ctf-create.c (ctf_add_forward): Don't add forwards to
types that already exist.
Nick Alcock [Mon, 21 Oct 2019 10:27:43 +0000 (11:27 +0100)]
libctf: create: non-root-visible types should not appear in name tables
We were accidentally interning newly-added and newly-opened
non-root-visible types into name tables, and removing names from name
tables when such types were removed. This is very wrong: the whole
point of non-root-visible types is they do not go in name tables and
cannot be looked up by name. This bug made non-root-visible types
basically identical to root-visible types, right back to the earliest
days of libctf in the Solaris era.
libctf/
* ctf-open.c (init_types): Only intern root-visible types.
* ctf-create.c (ctf_dtd_insert): Likewise.
(ctf_dtd_delete): Only remove root-visible types.
(ctf_rollback): Likewise.
(ctf_add_generic): Adjust.
(ctf_add_struct_sized): Adjust comment.
(ctf_add_union_sized): Likewise.
(ctf_add_enum): Likewise.
* ctf-impl.h (ctf_dtd_insert): Adjust prototype.
Nick Alcock [Mon, 30 Sep 2019 14:04:05 +0000 (15:04 +0100)]
binutils, ld: work with --disable-libctf
This unfortunately means conditionalizing out all the libctf code, but
the result is not too unbearably ugly, if a bit repetitive. I have
stubbed out code in the !ENABLE_LIBCTF path to avoid extra redundant
ifdefs where it seems that might be helpful. (The stubs are not too
disruptive, but I've tried to keep them on one line where possible to
avoid filling up the screen with stubs that nobody would care about.
If this is too much of a coding style violation I can change it.)
Changes since v2: use GCC_ENABLE rather than repeating all the
AC_ARG_ENABLE stuff over and over again.
ld/
* configure.ac [--enable-libctf]: New, default yes.
Set ENABLE_LIBCTF accordingly.
* Makefile.am [!ENABLE_LIBCTF]: Empty LIBCTF.
* configure: Regenerate.
* config.in: Regenerate.
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* ldlang.c (ctf_output): Conditionalize on ENABLE_LIBCTF.
(ldlang_open_ctf): Likewise.
(lang_merge_ctf): Likewise.
(ldlang_ctf_apply_strsym): Likewise.
(lang_write_ctf): Likewise.
(ldlang_write_ctf_late): Likewise.
(ldlang_open_ctf) [!ENABLE_LIBCTF]: Warn about the presence of CTF
sections.
(lang_merge_ctf) [!ENABLE_LIBCTF]: New stub.
(ldlang_ctf_apply_strsym) [!ENABLE_LIBCTF]: Likewise.
(lang_write_ctf) [!ENABLE_LIBCTF]: Likewise.
(ldlang_write_ctf_late) [!ENABLE_LIBCTF]: Likewise.
* ldelfgen.c (ldelf_emit_ctf_early): Conditionalize on
ENABLE_LIBCTF.
(struct ctf_strsym_iter_cb_arg): Likewise.
(ldelf_ctf_strtab_iter_cb): Likewise.
(ldelf_ctf_symbols_iter_cb): Likewise.
(ldelf_examine_strtab_for_ctf): Likewise.
(ldelf_emit_ctf_early) [!ENABLE_LIBCTF]: New stub.
(ldelf_examine_strtab_for_ctf) [!ENABLE_LIBCTF]: New stub.
binutils/
* configure.ac [--enable-libctf]: New, default yes.
Set ENABLE_LIBCTF accordingly.
* Makefile.am [!ENABLE_LIBCTF]: Empty LIBCTF and LIBCTF_NOBFD.
* configure: Regenerate.
* config.in: Regenerate.
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* objdump.c (usage): Conditionalize portions on ENABLE_LIBCTF.
(option_values): Likewise.
(long_options): Likewise.
(main): Likewise.
(dump_ctf_indent_lines): Conditionalize out when !ENABLE_LIBCTF.
(make_ctfsect): Likewise.
(dump_ctf_archive_member): Likewise.
(dump_ctf) [ENABLE_LIBCTF]: Likewise.
(dump_ctf) [!ENABLE_LIBCTF]: New empty stub.
* readelf.c (options): Conditionalize portions on ENABLE_LIBCTF.
(usage): Likewise.
(process_section_contents): Likewise.
(shdr_to_ctf_sect): Conditionalize out when !ENABLE_LIBCTF.
(dump_ctf_indent_lines): Likewise.
(dump_section_as_ctf) [ENABLE_LIBCTF]: Likewise.
Nick Alcock [Wed, 9 Oct 2019 09:42:00 +0000 (10:42 +0100)]
Fix --enable-libctf and --disable-static
This fixes test runs and compilation when --disable-libctf,
--disable-static, or --enable-shared are passed.
Changes since v2: Use GCC_ENABLE and fix indentation. Fix prototype
using 'void'. Use 'unsupported' and gdb_caching_proc.
Changes since v3: Adapt to upstream changes providing skip_ctf_tests.
Changes since v4: Adapt to upstream changes in the seven months (!)
since I last looked at this.
gdb/ChangeLog
* configure.ac: Add --enable-libctf: handle --disable-static
properly.
* acinclude.m4: sinclude ../config/enable.m4.
* Makefile.in (aclocal_m4_deps): Adjust accordingly.
(LIBCTF): Substitute in.
(CTF_DEPS): New, likewise.
(CLIBS): libctf needs symbols from libbfd: move earlier.
(CDEPS): Use CTF_DEPS, not LIBCTF, now LIBCTF can include rpath
flags.
* ctfread.c: Surround in ENABLE_LIBCTF.
(elfctf_build_psymtabs) [!ENABLE_LIBCTF]: New stub.
* configure: Regenerate.
* config.in: Likewise.
gdb/testsuite/ChangeLog
* configure.ac: Add --enable-libctf.
* aclocal.m4: sinclude ../config/enable.m4.
* Makefile.in (site.exp): Add enable_libctf to site.exp.
* lib/gdb.exp (skip_ctf_tests): Use it.
* gdb.base/ctf-constvars.exp: Error message tweak.
* gdb.base/ctf-ptype.exp: Likewise.
* configure: Regenerate.
Jan Beulich [Fri, 26 Jun 2020 14:44:31 +0000 (16:44 +0200)]
x86: make I disassembler macro available for new use
The {Q|Q} construct on lgdt/lidt and the slightly different {Q|IQ}
struck me as odd when encountering. Realizing they both have the same
effect, let's free up the I macro by using the former form of construct
where needed (there aren't that many uses overall).
With there now being several multi-character macros also re-do "alt"
handling slightly: Terminate it when finding the closing brace, rather
than after the next single character. Also set the flag only when
actually in Intel syntax mode.
Jan Beulich [Fri, 26 Jun 2020 14:43:38 +0000 (16:43 +0200)]
ld/x86: actually invoke k1om tests
Unlike claimed by the ChangeLog entries added by
7a9068fe1646 ("Add
initial Intel K1OM support") these tests did never get enabled.
Jan Beulich [Fri, 26 Jun 2020 14:42:55 +0000 (16:42 +0200)]
x86: fix processing of -M disassembler option
Multiple -M options can be specified in any order. Therefore stright
assignment to fields affected needs to be avoided, such that earlier
options' effects won't be discarded. This was in particular a problem
for -Msuffix followed by certain of the other sub-options.
While updating documentation, take the liberty and also drop the
redundant mentioning of being able to comma-separate multiple options.
Gary Benson [Fri, 26 Jun 2020 13:53:28 +0000 (14:53 +0100)]
Fix -Wstring-compare testcase build failure
Clang fails to compile the file gdb/testsuite/gdb.cp/try_catch.cc
with the following error:
warning: result of comparison against a string literal is
unspecified (use strncmp instead) [-Wstring-compare]
This commit fixes the error, replacing the pointer comparison with
a call to strcmp. This commit also adds a final check: the test
program is run to the final return statement, and the value of
"test" is checked to ensure it is still "true" at that point.
gdb/testsuite/ChangeLog:
* gdb.cp/try_catch.cc: Include string.h.
(main): Replace comparison against string literal with
strcmp, avoiding build failure with -Wstring-compare.
Add "marker test-complete".
* gdb.cp/try_catch.exp: Run the test to the above marker,
then verify that the value of "test" is still true.
Eli Zaretskii [Fri, 26 Jun 2020 06:51:45 +0000 (09:51 +0300)]
Improve documentation of which shell is used by GDB's shell commands
gdb/doc/ChangeLog:
2020-06-26 Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Shell Commands): More accurate description of use
of $SHELL. Reported by Sandra Loosemore <sandra@codesourcery.com>.
Pat Bernardi [Thu, 25 Jun 2020 20:05:38 +0000 (16:05 -0400)]
m68k: tag floating-point ABI used
This patch adds GNU attribute support to m68k and utilises it to tag the
floating-point calling convention used (hard-float or soft-float). It enables
the linker to ensure linked objects use a consistent floating-point ABI and
allows tools like GDB to infer the ABI used from the ELF file. It is based on
similar work done for PowerPC.
bfd/
* elf32-m68k.c (m68k_elf_merge_obj_attributes): New function.
(elf32_m68k_merge_private_bfd_data): Merge GNU attributes.
binutils/
* readelf.c (display_m68k_gnu_attribute): New function.
(process_arch_specific): Call display_m68k_gnu_attribute for EM_68K.
gas/
* config/tc-m68k.c (m68k_elf_gnu_attribute): New function.
(md_pseudo_table): Handle "gnu_attribute".
* doc/as.texi: Document GNU attribute for M68K.
include/
* elf/m68k.h: Add enum for GNU object attribute with floating point
tag name and values.
ld/
* testsuite/ld-m68k/attr-gnu-4-0.s: New file.
* testsuite/ld-m68k/attr-gnu-4-1.s: Likewise.
* testsuite/ld-m68k/attr-gnu-4-2.s: Likewise.
* testsuite/ld-m68k/attr-gnu-4-00.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-01.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-02.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-10.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-11.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-12.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-20.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-21.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-22.d: Likewise.
* testsuite/ld-m68k/m68k.exp: Run the new tests.
Alan Modra [Fri, 26 Jun 2020 01:22:30 +0000 (10:52 +0930)]
RISCV changes broke 32-bit --enable-targets=all
By the look of it, git commit
39ff0b812324 broke 32-bit host
--enable-targets=all binutils builds.
/usr/local/bin/ld: ../opcodes/.libs/libopcodes.a(riscv-dis.o): in function `parse_riscv_dis_option':
/home/alan/src/binutils-gdb/opcodes/riscv-dis.c:102: undefined reference to `riscv_get_priv_spec_class'
collect2: error: ld returned 1 exit status
Makefile:925: recipe for target 'objdump' failed
The problem is that elfxx-riscv.c is not built for a 32-bit host
without --enable-64-bit-bfd or unless RISCV is given specifically as a
target. No such trimming of 64-bit only targets is done in opcodes.
One solution is to move these support functions to cpu-riscv.c, which
runs into "error: implicit declaration of function ‘xmalloc’". Now,
xmalloc is not supposed to be used in libbfd or libopcodes - it's rude
to crash out of an application that calls libbfd or libopcodes
functions without giving it a chance to deal with out-of-memory
itself. So I removed the xmalloc and instead used a fixed size
buffer. If you are worried about adding 36 bytes for the buffer to
the riscv_get_priv_spec_class_from_numbers stack frame size, then you
have no idea of the likely xmalloc + malloc stack frame size! Trying
to reduce memory usage is commendable, but in this instance
riscv_estimate_digit and malloc for a temp buffer uses a lot more
memory than a fixed max-size buffer.
* elfxx-riscv.c (struct priv_spec_t, priv_specs),
(riscv_get_priv_spec_class, riscv_get_priv_spec_class_from_numbers),
(riscv_get_priv_spec_name): Move to..
* cpu-riscv.c: ..here.
(riscv_get_priv_spec_class_from_numbers): Don't xmalloc temp buffer.
Use %u to print unsigned numbers.
GDB Administrator [Fri, 26 Jun 2020 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Thu, 25 Jun 2020 21:06:18 +0000 (17:06 -0400)]
gdb: use make_unique_xstrdup in set_inferior_io_terminal
gdb/ChangeLog:
* infcmd.c (set_inferior_io_terminal): Use make_unique_xstrdup.
Change-Id: I38b6e753f58947531fe4a293d574bc27ec128f47
Simon Marchi [Thu, 25 Jun 2020 18:44:13 +0000 (14:44 -0400)]
gdb: make inferior::terminal a unique ptr
This changes the inferior::terminal field to be a unique pointer, so its
deallocation is automatically managed.
gdb/ChangeLog:
* inferior.h (struct inferior) <terminal>: Change type to
gdb::unique_xmalloc_ptr<char>.
* inferior.c (inferior::~inferior): Don't free inf->terminal.
* infcmd.c (set_inferior_io_terminal): Don't free terminal
field, adjust to unique pointer.
(get_inferior_io_terminal): Adjust to unique pointer.
Change-Id: Iedb6459b4f9eeae812b0cb9d514b5707d5107cdb
David Faust [Thu, 25 Jun 2020 18:34:29 +0000 (20:34 +0200)]
cpu: fix offset16 type, update c-calls in bpf.cpu
Correct the type of the offset16 field to HI, and simplify memory
accesses which use it. Also update c-calls in semantics for a
few instructions.
cpu/ChangeLog:
2020-06-25 David Faust <david.faust@oracle.com>
* bpf.cpu (f-offset16): Change type from INT to HI.
(dxli): Simplify memory access.
(dxsi): Likewise.
(define-endian-insn): Update c-call in semantics.
(dlabs) Likewise.
(dlind) Likewise.
Andrew Burgess [Tue, 16 Jun 2020 16:00:33 +0000 (17:00 +0100)]
gdb/riscv: Loop over all registers for 'info all-registers'
Currently the 'info all-registers' command only loops over those
registers that are known to GDB. Any registers that are unknown, that
is, are mentioned in the target description, but are not something GDB
otherwise knows, will not be displayed.
This feels wrong, so this commit fixes this mistake. The output of
'info all-registers' now matches 'info registers all'.
gdb/ChangeLog:
* riscv-tdep.c (riscv_print_registers_info): Loop over all
registers, not just the known core set of registers.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-tdesc-regs.exp: New test cases.
Andrew Burgess [Tue, 16 Jun 2020 13:53:12 +0000 (14:53 +0100)]
gdb/riscv: Record information about unknown tdesc registers
Making use of the previous commit, record information about unknown
registers in the target description, and use this to resolve two
issues.
1. Some targets (QEMU) are reporting three register fflags, frm, and
fcsr, twice, once in the FPU feature, and once in the CSR feature.
GDB does create two registers with identical names, but this
is (sort of) fine, we only ever use the first one, and as both
registers access the same target state things basically work OK.
The only real problem is that the register names show up twice in
'info registers all' output.
In this commit we spot the duplicates of these registers and then
return NULL when asked for the name of these registers. This
causes GDB to hide these registers from the user, fixing this
problem.
2. Some targets (QEMU) advertise CSRs that GDB then can't read. The
problem is these targets also say these CSRs are part of the
save/restore register groups.
This means that before an inferior call GDB tries to save all of
these CSRs, and a failure to read one causes the inferior call to
be abandoned.
We already work around this issue to some degree, known CSRs are
removed from the save/restore groups, despite what the target might
say. However, any unknown CSRs are (currently) not removed in this
way.
After this commit we keep a log of the register numbers for all
unknown CSRs, then when asked about the register groups, we
override the group information for unknown CSRs, removing them from
the save and restore groups.
gdb/ChangeLog:
* riscv-tdep.c (riscv_register_name): Return NULL for duplicate
fflags, frm, and fcsr registers.
(riscv_register_reggroup_p): Remove unknown CSRs from save and
restore groups.
(riscv_tdesc_unknown_reg): New function.
(riscv_gdbarch_init): Pass riscv_tdesc_unknown_reg to
tdesc_use_registers.
* riscv-tdep.h (struct gdbarch_tdep): Add
unknown_csrs_first_regnum, unknown_csrs_count,
duplicate_fflags_regnum, duplicate_frm_regnum, and
duplicate_fcsr_regnum fields.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-tdesc-regs.exp: Extend test case.
Andrew Burgess [Tue, 16 Jun 2020 12:14:04 +0000 (13:14 +0100)]
gdb: Extend target description processing of unknown registers
This commit adds a new step to the processing of a target description
done in tdesc_use_registers, this new step is about how unknown
registers are processed.
Currently an architecture looks through the target description and
calls tdesc_numbered_register for each register is was expecting (or
hoping) to find. This builds up a map from GDB's register numbers to
the tdesc_reg object. Later the architecture calls
tdesc_use_registers.
In tdesc_use_registers we build a hash with keys being all the
tdesc_reg object pointers, from this hash we remove all of the
tdesc_reg objects that were assigned register numbers using
tdesc_numbered_register.
Finally we walk through all of the tdesc_reg objects, and if it was
not already assigned a number we assign that register the next
available number.
The problem with this is that the architecture has no visibility of
which unknown registers exist, and which tdesc_feature the register
came from, in some cases this might be important.
For example, on RISC-V GDB overrides the use of
tdesc_register_reggroup_p, with riscv_register_reggroup_p to modify
some of the register group choices. In this function GDB wants to
treat all registers from a particular feature in a certain way. This
is fine for registers that GDB knows might be in that feature, but for
unknown registers the RISC-V parts of GDB have no easy way to figure
out which unknown registers exist, and what numbers they were
assigned.
We could figure this information out by probing the register
structures after calling tdesc_use_registers, but this would be
horrible, much better to have tdesc_use_registers tell the
architecture about unknown registers.
This is what this commit does. A new phase of tdesc_use_registers,
just before the unknown registers are assigned a number, we loop over
each tdesc_reg object, if it has not been assigned a number then we
figure out what number would be assigned and then call back into the
architecture passing the tdesc_feature, register name, and the
proposed register number.
The architecture is free to return the proposed register number, or it
can return a different number (which has a result identical to having
called tdesc_numbered_register). Alternatively the architecture can
return -1 to indicate the register should be numbered later.
After calling the callback for every tdesc_reg object any registers
still don't have a number assigned (because the architecture returned
-1), then a new register number is assigned, which might be different
from the proposed number that was suggested earlier.
This commit adds the general target-description parts of this
mechanism. No targets are currently using this code. The RISC-V
target will make use of this in the next commit.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* target-descriptions.c (tdesc_use_registers): Add new parameter a
callback, use the callback (when not null) to help number unknown
registers.
* target-descriptions.h (tdesc_unknown_register_ftype): New typedef.
(tdesc_use_registers): Add extra parameter to declaration.
Andrew Burgess [Tue, 16 Jun 2020 09:02:09 +0000 (10:02 +0100)]
gdb/riscv: Improve support for matching against target descriptions
For the RISC-V target it is desirable if the three floating pointer
status CSRs fflags, frm, and fcsr can be placed into either the FPU
feature or the CSR feature. This allows different targets to build
the features in a way that better reflects their target.
The change to support this within GDB is fairly simple, so this is
done in this commit, and some tests added to check this new
functionality.
gdb/ChangeLog:
* riscv-tdep.c (value_of_riscv_user_reg): Moved to here from later
in the file.
(class riscv_pending_register_alias): Likewise.
(riscv_register_feature::register_info): Change 'required_p' field
to 'required', and change its type. Add 'check' member function.
(riscv_register_feature::register_info::check): Define new member
function.
(riscv_xreg_feature): Change initialisation of 'required' field.
(riscv_freg_feature): Likewise.
(riscv_virtual_feature): Likewise.
(riscv_csr_feature): Likewise.
(riscv_check_tdesc_feature): Take extra parameter, the csr
tdesc_feature, rewrite the function to use the new
riscv_register_feature::register_info::check function.
(riscv_gdbarch_init): Pass the csr tdesc_feature where needed.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-tdesc-loading-01.xml: New file.
* gdb.arch/riscv-tdesc-loading-02.xml: New file.
* gdb.arch/riscv-tdesc-loading-03.xml: New file.
* gdb.arch/riscv-tdesc-loading-04.xml: New file.
* gdb.arch/riscv-tdesc-loading.exp: New file.
Andrew Burgess [Mon, 15 Jun 2020 18:22:22 +0000 (19:22 +0100)]
gdb/riscv: Remove CSR feature file
There is currently a bug in the RISC-V CSR/FPU feature files. The
CSRs containing the FPU status registers are mentioned in both the FPU
feature file and the CSR feature file.
My original thinking when adding the FPU feature file was that it made
more sense to group the FPU status registers with the other FPU
state. This opened up the possibility of debugging very
simple (possibly simulator only) targets that had little more than CPU
and FPU available for GDB to access.
When I then added code to automatically generate the CSR XML file I
forgot to filter out the FPU status CSRs, so these registers were
mentioned twice.
Now for GDB's default RISC-V target descriptions this doesn't actually
matter. I did consider adding the CSRs to the default target
description, but in the end I didn't bother. The reasoning again was
simplicity; the default target description is only to be used when the
target doesn't supply its own description, and NOT supplying the CSRs
actually serves to encourage targets to supply an accurate
description. Combine this with the fact that the CSRs change from
revision to revision, sometimes in non-backward compatible ways, then
having a "default" set of CSRs just feels like a path to confusion and
complaints.
However, having a broken CSR XML file in the GDB source tree has had
one negative effect, QEMU has copied this file into its source tree,
and is using this as its description that it passes to GDB. That is
QEMU announces the FPU status registers twice, once in the FPU
feature, and once in the CSR feature.
This commit starts along the path back to sanity by deleting the
default CSR XML files from within GDB. These files were not used in
any way by current GDB, so there is absolutely no loss of
functionality with this change.
gdb/ChangeLog:
* features/Makefile: Remove all references to the deleted files
below.
* features/riscv/32bit-csr.c: Deleted.
* features/riscv/32bit-csr.xml: Deleted.
* features/riscv/64bit-csr.c: Deleted.
* features/riscv/64bit-csr.xml: Deleted.
* features/riscv/rebuild-csr-xml.sh: Deleted.
Andrew Burgess [Thu, 11 Jun 2020 10:49:05 +0000 (11:49 +0100)]
gdb/riscv: Take CSR names from target description
First, consider the RISC-V register $x1. This register has an alias
$ra. When GDB processes an incoming target description we allow the
target to use either register name to describe the target.
However, within GDB's UI we want to use the $ra alias in preference to
the $x1 architecture name.
To achieve this GDB overrides the tdesc_register_name callback with
riscv_register_name. In riscv_register_name we ensure that we always
return the preferred name, so in this case "ra".
To ensure the user can still access the register as $x1 if they want
to, when in riscv_check_tdesc_feature we spot that the target has
supplied the register, we add aliases for every name except the
preferred one, so in this case we add the alias "x1".
This scheme seems to work quite well, the targets have the flexibility
to be architecture focused if they wish (using x0 - x31) while GDB is
still using the ABI names ra, sp, gp, etc.
When this code was originally added there was an attempt made to
include the CSRs in the same scheme. At the time the CSRs only had
two names, one pulled from riscv-opc.h, and one generated in GDB that
had the pattern csr%d.
The idea was that if the remote targets description described the CSRs
as csr%d then GDB would rename these back to the real CSR name. This
code was only included because if followed the same pattern as the
x-regs and f-regs, not because I was actually aware of any target that
did this.
However, recent changes to add additional CSR aliases has made me
rethink the position here.
Lets consider the CSR $dscratch0. This register has an alias
'csr1970' (1970 is 0x7b2, which is the offset of the CSR register into
the CSR address space). However, this register was originally called
just 'dscratch', and so, after recent commits, this register also has
the alias 'dscratch'.
As the riscv-opc.h file calls this register 'dscratch0' GDB's
preferred name for this register is 'dscratch0'.
So, if the remote target description includes the register
'dscratch0', then GDB will add the aliases 'dscratch', and 'csr1970'.
In the UI GDB will describe the register as 'dscratch0', and all it
good.
The problem I see in this case is where the target describes the
register as 'dscratch'. In this case GDB will still spot the register
and add the aliases 'dscratch', and 'csr1970', GDB will then give the
register the preferred name 'dscratch0'.
I don't like this. For the CSRs I think that we should stick with the
naming scheme offered by the remote target description. As the RISC-V
specification evolves and CSR register names evolve, insisting on
referring to registers by the most up to date name makes it harder for
a target to provide a consistent target description for an older
version of the RISC-V architecture spec.
In this precise case the target offers 'dscratch', which is from an
older version of the RISC-V specification, the newer version of the
spec has two registers 'dscratch0' and 'dscratch1'. If we insist on
using 'dscratch0' it is then a little "weird" (or seems so to me) when
'dscratch1' is missing.
This patch makes a distinction between the x and f registers and the
other register sets. For x and f we still make use of the renaming
scheme, forcing GDB to prefer the ABI name. But after this patch the
CSR register group, and also the virtual register group, will always
prefer to use the name given in the target description, adding other
names as aliases, but not making any other name the preferred name.
gdb/ChangeLog:
* riscv-tdep.c (struct riscv_register_feature::register_info): Fix
whitespace error for declaration of names member variable.
(struct riscv_register_feature): Add new prefer_first_name member
variable, and fix whitespace error in declaration of registers.
(riscv_xreg_feature): Initialize prefer_first_name field.
(riscv_freg_feature): Likewise.
(riscv_virtual_feature): Likewise.
(riscv_csr_feature): Likewise.
(riscv_register_name): Expand on comments. Remove register name
modifications for CSR and virtual registers.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-tdesc-regs.exp: Extend test case.
Andrew Burgess [Tue, 16 Jun 2020 09:06:35 +0000 (10:06 +0100)]
gdb/riscv: Fix whitespace error
Should be 'std::vector<type>' not 'std::vector <type>'.
gdb/ChangeLog:
* riscv-tdep.c (struct riscv_register_feature): Fix whitespace
errors.
Andrew Burgess [Tue, 9 Jun 2020 16:38:30 +0000 (17:38 +0100)]
gdb/riscv: Improved register alias name creation
This commit does two things:
1. Makes use of the DECLARE_CSR_ALIAS definitions in riscv-opc.h to
add additional aliases for CSRs.
2. Only creates aliases for registers that are actually present on
the target (as announced in the target XML description).
This means that the 'csr%d' aliases that exist will only be created
for those CSRs the target actually has, which is a nice improvement,
as accessing one of the CSRs that didn't exist would cause GDB to
crash with this error:
valprint.c:1560: internal-error: bool maybe_negate_by_bytes(const gdb_byte*, unsigned int, bfd_endian, gdb::byte_vector*): Assertion `len > 0' failed.
When we look at the DECLARE_CSR_ALIAS lines in riscv-opc.h, these can
be split into three groups:
DECLARE_CSR_ALIAS(misa, 0xf10, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P9P1)
The 'misa' register used to exist of offset 0xf10, but was moved to
its current offset (0x301) in with privilege spec 1.9.1. We don't
want GDB to create an alias called 'misa' as we will already have a
'misa' register created by the DECLARE_CSR(misa ....) call earlier in
riscv-opc.h
DECLARE_CSR_ALIAS(ubadaddr, CSR_UTVAL, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10)
DECLARE_CSR_ALIAS(sbadaddr, CSR_STVAL, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10)
DECLARE_CSR_ALIAS(sptbr, CSR_SATP, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10)
DECLARE_CSR_ALIAS(mbadaddr, CSR_MTVAL, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10)
DECLARE_CSR_ALIAS(mucounteren, CSR_MCOUNTINHIBIT, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10)
These aliases are all CSRs that were removed in privilege spec 1.10,
and whose addresses were reused by new CSRs. The names meaning of the
old names is totally different to the new CSRs that have taken their
place. I don't believe we should add these as aliases into GDB. If
the new CSR exists in the target then that should be enough.
DECLARE_CSR_ALIAS(dscratch, CSR_DSCRATCH0, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P11)
In privilege spec 1.11 the 'dscratch' register was renamed to
'dscratch0', however the meaning of the register didn't change.
Adding the 'dscratch' alias makes sense I think.
Looking then at the final PRIV_SPEC_CLASS_* field for each alias then
we can see that currently we only want to take the alias from
PRIV_SPEC_CLASS_1P11. For now then this is what I'm using to filter
the aliases within GDB.
In the future there's no telling how DECLARE_CSR_ALIAS will be used.
I've heard it said that future RISC-V privilege specs will not reuse
CSR offsets again. But it could happen. We just don't know.
If / when it does we may need to revisit how aliases are created for
GDB, but for now this seems to be OK.
gdb/ChangeLog:
* riscv-tdep.c (riscv_create_csr_aliases): Handle csr aliases from
riscv-opc.h.
(class riscv_pending_register_alias): New class.
(riscv_check_tdesc_feature): Take vector of pending aliases and
populate it as appropriate.
(riscv_setup_register_aliases): Delete.
(riscv_gdbarch_init): Create vector of pending aliases and pass it
to riscv_check_tdesc_feature in all cases. Use the vector to
create the register aliases.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-tdesc-regs-32.xml: New file.
* gdb.arch/riscv-tdesc-regs-64.xml: New file.
* gdb.arch/riscv-tdesc-regs.c: New file.
* gdb.arch/riscv-tdesc-regs.exp: New file.
Rainer Orth [Thu, 25 Jun 2020 15:56:12 +0000 (17:56 +0200)]
Remove obsolete gdbarch_static_transform_name
gdbarch_static_transform_name is completely Solaris-specific or rather
specific to the Studio compilers. Studio cc has deprecated Stabs support
in the 12.4 release back in 2015, GCC has defaulted to DWARF-2 on Solaris
7+ since 2004 and Stabs themselves are pretty much obsolete, so the whole
code can go.
Tested on sparcv9-sun-solaris2.11 and x86_64-pc-linux-gnu with
--enable-targets=all.
* sol2-tdep.c (sol2_static_transform_name): Remove.
(sol2_init_abi): Don't register it.
* gdbarch.sh (static_transform_name): Remove.
* gdbarch.c, gdbarch.h: Regenerate.
* dbxread.c (read_dbx_symtab) <'S'>: Remove call to
gdbarch_static_transform_name.
* mdebugread.c (parse_partial_symbols) <'S'>: Likewise.
* stabsread.c (define_symbol) <'X'>: Remove.
(define_symbol) <'S'>: Remove gdbarch_static_transform_name
handling.
<'V'>: Likewise.
* xcoffread.c (scan_xcoff_symtab): Remove gdbarch.
<'S'>: Remove call to gdbarch_static_transform_name.
Rainer Orth [Thu, 25 Jun 2020 15:48:14 +0000 (17:48 +0200)]
Use fork instead of vfork on Solaris
The gdb.mi/mi-exec-run.exp test never completed/timed out on Solaris for
quite some time:
FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected (timeout)
This is for gdb trying to exec mi-exec-run.nox, a copy of mi-exec-run
with execute permissions removed.
The process tree at this point looks like this:
21254 /vol/gcc/bin/expect -- /vol/gcc/share/dejagnu/runtest.exp GDB_PARALLEL=yes --outdir=outputs/gdb.mi/mi-exec-run-vfork gdb.mi/mi-exec-run.exp
21300 <defunct>
21281 <defunct>
21294 $obj/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory $obj/gdb/testsuite/../data-directory -i=mi
21297 $obj/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory $obj/gdb/testsuite/../data-directory -i=mi
The parent gdb hangs here:
21294: $obj/gdb/testsuite/../../gdb/gdb -nw
------------ lwp# 1 / thread# 1 ---------------
0000000000000000 SYS#0 ()
0000000000daeccd procfs_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, int) () + 97 (procfs.c:2853)
0000000000ca63a7 run_command_1(char const*, int, run_how) () + 349 (basic_string.h:187)
0000000000ca6516 start_command(char const*, int) () + 26 (infcmd.c:584)
0000000000b3ca8e do_const_cfunc(cmd_list_element*, char const*, int) () + f (cli-decode.c:96)
0000000000b3ed77 cmd_func(cmd_list_element*, char const*, int) () + 32 (cli-decode.c:2113)
0000000000f2d219 execute_command(char const*, int) () + 455 (top.c:657)
0000000000d4ad77 mi_execute_cli_command(char const*, int, char const*) () + 242 (basic_string.h:187)
0000000000d4ae80 mi_cmd_exec_run(char const*, char**, int) () + ba (mi-main.c:473)
with these process flags
21294: $obj/gdb/testsuite/../../gdb/gdb -nw
data model = _LP64 flags = VFORKP|ORPHAN|MSACCT|MSFORK
sigpend = 0x00004103,0x00000000,0x00000000
/1: flags = 0
sigmask = 0xffbffeff,0xffffffff,0x000000ff
cursig = SIGKILL
/2: flags = DETACH|STOPPED|ASLEEP lwp_park(0x0,0x0,0x0)
why = PR_SUSPENDED
sigmask = 0x000a2002,0x00000000,0x00000000
[...]
while the child sits at
21297: $obj/gdb/testsuite/../../gdb/gdb -nw
00007fffbf078a0b execve (
7fffbffff756,
7fffbfffec58,
7fffbfffec90, 0)
00007fffbef84cf6 execvpex () + f6
00007fffbef84f45 execvp () + 15
0000000000d60a44 fork_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, void (*)(), gdb::function_view<void (int)>, void (*)(), char const*, void (*)(char const*, char* const*, char* const*)) () + 47f (fork-inferior.c:423)
0000000000daeccd procfs_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, int) () + 97 (procfs.c:2853)
0000000000ca63a7 run_command_1(char const*, int, run_how) () + 349 (basic_string.h:187)
0000000000ca6516 start_command(char const*, int) () + 26 (infcmd.c:584)
0000000000b3ca8e do_const_cfunc(cmd_list_element*, char const*, int) () + f (cli-decode.c:96)
0000000000b3ed77 cmd_func(cmd_list_element*, char const*, int) () + 32 (cli-decode.c:2113)
0000000000f2d219 execute_command(char const*, int) () + 455 (top.c:657)
0000000000d4ad77 mi_execute_cli_command(char const*, int, char const*) () + 242 (basic_string.h:187)
0000000000d4ae80 mi_cmd_exec_run(char const*, char**, int) () + ba (mi-main.c:473)
with
21297: $obj/gdb/testsuite/../../gdb/gdb -nw
data model = _LP64 flags = MSACCT|MSFORK
exitset = 0x00000000 0x04000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000
/1: flags = STOPPED|ISTOP execve(0x7fffbffff756,0x7fffbfffec58,0x7fffbfffec90,0x0)
why = PR_SYSEXIT what = execve
We have a deadlock here: the execve in the child cannot return until the
parent has handled the PR_SYSEXIT while the parent cannot run with a
vfork'ed child as documented in proc(4):
The child of a vfork(2) borrows the parent's address space. When a
vfork(2) is executed by a traced process, all watched areas established
for the parent are suspended until the child terminates or performs an
exec(2). Any watched areas established independently in the child are
cancelled when the parent resumes after the child's termination or
exec(2). PCWATCH fails with EBUSY if applied to the parent of a
vfork(2) before the child has terminated or performed an exec(2). The
PR_VFORKP flag is set in the pstatus structure for such a parent
process.
In that situation, the parent cannot be killed even with SIGKILL (as
runtest will attempt once the timeout occurs; the pending signal can be
seen in the pflags output above), so the whole test hangs until one
manually kills the child process.
Fortunately, there's an easy way out: when using fork instead of vfork,
the problem doesn't occur, and this is what the current patch does: it
calls fork_inferior with a dummy pre_trace_fun arg.
Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11.
* procfs.c (procfs_pre_trace): New function.
(procfs_target::create_inferior): Pass it to fork_inferior.
Rainer Orth [Thu, 25 Jun 2020 11:54:42 +0000 (13:54 +0200)]
Don't include *sol2-tdep.o on Linux/sparc*
Linux/sparc* currently links Solaris-specific files (sparc-sol2-tdep.o,
sparc64-sol2-tdep.o, sol2-tdep.o) for no apparent reason. It has no
business doing so, and none of the functions/variables defined there are
used explicitly. If support for the Solaris OSABI were desired, this
should be done using --enable-targets instead.
Since neither sparc{32,64}_sol2_init_abi currently declared in common
headers (sparc*-tdep.h) are used outside their source files, they are made
static and the declarations removed.
Tested on sparcv9-sun-solaris2.11 and sparc64-unknown-linux-gnu.
* configure.tgt <sparc-*-linux*> (gdb_target_obs): Remove
sparc-sol2-tdep.o, sol2-tdep.o, sparc64-sol2-tdep.o.
<sparc64-*-linux*> (gdb_target_obs): Remove sparc64-sol2-tdep.o,
sol2-tdep.o, sparc-sol2-tdep.o.
* sparc-sol2-tdep.c (sparc32_sol2_init_abi): Make static.
* sparc-tdep.h (sparc32_sol2_init_abi): Remove.
* sparc64-sol2-tdep.c (sparc64_sol2_init_abi): Make static.
* sparc64-tdep.h (sparc64_sol2_init_abi): Remove.
Rainer Orth [Thu, 25 Jun 2020 11:43:46 +0000 (13:43 +0200)]
Move common handlers to sol2_init_abi
There's some overlap and duplication between 32 and 64-bit Solaris/SPARC
and x86 tdep files, in particular
sol2_core_pid_to_str
*_sol2_sigtramp_p
sol2_skip_solib_resolver
*_sol2_static_transform_name (forgotten on amd64)
set_gdbarch_sofun_address_maybe_missing (likewise)
This patch avoids this by centralizing common code in sol2-tdep.c.
While sparc_sol2_pc_in_sigtramp and sparc_sol2_static_transform_name
were declared in the shared sparc-tdep.h, they were only used in Solaris
files.
Tested on amd64-pc-solaris2.11, i386-pc-solaris2.11,
sparcv9-sun-solaris2.11, and sparc-sun-solaris2.11, and
sparc64-unknown-linux-gnu.
* amd64-sol2-tdep.c (amd64_sol2_sigtramp_p): Remove.
(amd64_sol2_init_abi): Use sol2_sigtramp_p.
Call sol2_init_abi.
Remove calls to set_gdbarch_skip_solib_resolver,
set_gdbarch_core_pid_to_str.
* i386-sol2-tdep.c (i386_sol2_sigtramp_p): Remove.
(i386_sol2_static_transform_name): Remove.
(i386_sol2_init_abi): Call sol2_init_abi.
Remove calls to set_gdbarch_sofun_address_maybe_missing,
set_gdbarch_static_transform_name,
set_gdbarch_skip_solib_resolver, set_gdbarch_core_pid_to_str.
Use sol2_sigtramp_p.
* sol2-tdep.c (sol2_pc_in_sigtramp): New function.
(sol2_sigtramp_p): New function.
(sol2_static_transform_name): New function.
(sol2_skip_solib_resolver, sol2_core_pid_to_str): Make static.
(sol2_init_abi): New function.
* sol2-tdep.h (sol2_sigtramp_p, sol2_init_abi): Declare.
(sol2_skip_solib_resolver, sol2_core_pid_to_str): Remove.
* sparc-sol2-tdep.c (sparc_sol2_pc_in_sigtramp): Remove.
(sparc32_sol2_sigtramp_frame_sniffer): Just call sol2_sigtramp_p.
(sparc_sol2_static_transform_name): Remove.
(sparc32_sol2_init_abi): Call sol2_init_abi.
Remove calls to set_gdbarch_sofun_address_maybe_missing,
set_gdbarch_static_transform_name,
set_gdbarch_skip_solib_resolver,
set_gdbarch_core_pid_to_str.
* sparc-tdep.h (sparc_sol2_pc_in_sigtramp)
(sparc_sol2_static_transform_name): Remove
* sparc64-sol2-tdep.c (sparc64_sol2_sigtramp_frame_sniffer): Just
call sol2_sigtramp_p.
(sparc64_sol2_init_abi): Call sol2_init_abi.
Remove calls to set_gdbarch_sofun_address_maybe_missing,
set_gdbarch_static_transform_name,
set_gdbarch_skip_solib_resolver, set_gdbarch_core_pid_to_str.
Nick Clifton [Thu, 25 Jun 2020 10:29:24 +0000 (11:29 +0100)]
Update the Swedish translation in the gprof/ subdirectory.
* po/sv.po: Updated Swedish translation.
Nick Clifton [Thu, 25 Jun 2020 10:16:42 +0000 (11:16 +0100)]
Remove the use of the register keyword in the libiberty.h header file - it is deprecated and incompatible with C++17.
* libiberty.h (bsearch_r): Remove use of the register keyword from
the prototype.
Nick Clifton [Thu, 25 Jun 2020 10:11:51 +0000 (11:11 +0100)]
Stop the assembler from generating R_ARM_THM_JMP11 relocations as these are not supported by the kernel.
PR 26141
* config/tc-arm.c (arm_force_relocation): Force resolution of
BFD_RELOC_THUMB_PCREL_BRANCH12 relocations.
* testsuite/gas/arm/plt-1.d: Adjust expected disassembly.
Jan Beulich [Thu, 25 Jun 2020 07:31:50 +0000 (09:31 +0200)]
x86: make J disassembler macro available for new use
There's clearly a shortage of available macro characters, as can be seen
from the various two-character macros that had to be introduced. Don't
waste characters for things that can be expressed differently. In the
case of J this alternative is {l|}.
Jan Beulich [Thu, 25 Jun 2020 07:30:39 +0000 (09:30 +0200)]
x86: drop left-over 4-way alternative disassembler templates
Commit
7c52e0e8658a, dropping the general concept of 4-way alternatives,
for whatever reason, omitted cleaning up these two instances.
Jan Beulich [Thu, 25 Jun 2020 07:30:09 +0000 (09:30 +0200)]
x86: move ImmExt processing
With abuses of ImmExt gone, all templates using it have operands. Move
its main invocation into process_operands(), matching its secondary one
for the SSE2AVX case.
Jan Beulich [Thu, 25 Jun 2020 07:29:29 +0000 (09:29 +0200)]
x86: operand sizing prefixes can disambiguate insns
Use of an explicit data size or REX.W prefix is sufficient indication of
the intended operation when operand size can't be derived from suffix or
register operands. Avoid the ambiguity warning and make in particular
immediate handling (sizing) cope with explicitly specified prefixes.
Extending/reusing the noreg16 test made me notice a few cases of
unintentional 32-bit addressing, which gets corrected at the same time.
Jan Beulich [Thu, 25 Jun 2020 07:27:21 +0000 (09:27 +0200)]
x86: fix SYSRET disassembly, improve {,V}CVTSI2S{S,D} and PTWRITE
SYSRET can't use the same macro as IRET, since there's no 16-bit operand
size form of it. Re-use LQ for it instead.
Doing so made obvious that outside of 64-bit mode {,V}CVTSI2S{S,D} and
PTWRITE should have an 'l' suffix printed only in suffix-always mode.
Jan Beulich [Thu, 25 Jun 2020 07:26:28 +0000 (09:26 +0200)]
x86-64: REX prefix is invalid with VEX etc
Just like for the data size prefix (see commit
7a8655d2bbdc ["x86: don't
abort() upon DATA16 prefix on (E)VEX encoded insn"]), any form of REX
prefix is invalid with VEX/XOP/EVEX.
Jan Beulich [Thu, 25 Jun 2020 07:25:52 +0000 (09:25 +0200)]
x86-64: honor REX prefixes for SSE2AVX
Legacy encoded insns do so, and their automatic conversion to AVX ones
ought to produce functionally identical code. Therefore explicit REX
prefixes cannot simply be ignored. This is in particular relevant
because at least PCMPESTR{I,M}'s 64-bit forms couldn't be expressed in
older gas by other than using a REX64 prefix.
Jan Beulich [Thu, 25 Jun 2020 07:25:12 +0000 (09:25 +0200)]
x86: also refuse data size prefix on SIMD insns
The data size prefix alters the meaning of legacy encoded SIMD insns,
and hence shouldn't be accepted there. Use of it also leads to
inconsistencies in SSE2AVX mode. Don't match insns with data size prefix
against SSE2AVX templates.
Jan Beulich [Thu, 25 Jun 2020 07:24:23 +0000 (09:24 +0200)]
x86: drop stray assignment from build_evex_prefix()
Unlike in build_vex_prefix() this is not needed here.
GDB Administrator [Thu, 25 Jun 2020 00:00:08 +0000 (00:00 +0000)]
Automatic date update in version.in
projects / binutils-gdb.git / log