Tom Tromey [Mon, 8 Mar 2021 14:27:57 +0000 (07:27 -0700)]
Implement dumping
This patch implements the dumping methods for tuple_holding_operation.
A number of overloads are used. Note that no default case is given.
This approach makes it simple to detect when a new overload is needed
-- compilation will fail. (There is an example of this in a later
patch in the series.)
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expprint.c (expr::dump_for_expression): New functions.
* expop.h (dump_for_expression): New overloads.
(tuple_holding_operation::dump, tuple_holding_operation::do_dump):
Update.
Tom Tromey [Mon, 8 Mar 2021 14:27:57 +0000 (07:27 -0700)]
Introduce class operation
This patch introduces class operation, the new base class for all
expression operations.
In the new approach, an operation is simply a class that presents a
certain interface. Operations own their operands, and management is
done via unique_ptr.
The operation interface is largely ad hoc, based on the evolution of
expression handling in GDB. Parts (for example,
evaluate_with_coercion) are probably redundant; however I took this
approach to try to avoid mixing different kinds of refactorings.
In some specific situations, rather than add a generic method across
the entire operation class hierarchy, I chose instead to use
dynamic_cast and specialized methods on certain concrete subclasses.
This will appear in some subsequent patches.
One goal of this work is to avoid the kinds of easy-to-make errors
that affected the old implementation. To this end, some helper
subclasses are also added here. These helpers automate the
implementation of the 'dump', 'uses_objfile', and 'constant_p'
methods. Nearly every concrete operation that is subsequently added
will use these facilities. (Note that the 'dump' implementation is
only outlined here, the body appears in the next patch.)
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* expression.h (expr::operation): New class.
(expr::make_operation): New function.
(expr::operation_up): New typedef.
* expop.h: New file.
* eval.c (operation::evaluate_for_cast)
(operation::evaluate_for_address, operation::evaluate_for_sizeof):
New methods.
* ax-gdb.c (operation::generate_ax): New method.
Tom Tromey [Mon, 8 Mar 2021 14:27:57 +0000 (07:27 -0700)]
Split gen_expr_binop_rest
This splits gen_expr_binop_rest into two overloads. One overload
retains the "pc" parameter, while the other does not, and furthermore
does not call gen_expr on the left-hand-side. This split is useful
for subsequent patches in the new expression evaluation approach.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* ax-gdb.c (gen_expr_binop_rest): Remove "pc" parameter.
(gen_expr_binop_rest): New overload.
Tom Tromey [Mon, 8 Mar 2021 14:27:57 +0000 (07:27 -0700)]
Change value_val_atr to ada_val_atr
This renames value_val_atr to ada_val_atr, changing its parameters to
more closely mirror other expression helpers. The
EVAL_AVOID_SIDE_EFFECTS case is moved into this function as well.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* ada-lang.c (ada_val_atr): Rename from value_val_atr. Change
parameters.
(ada_evaluate_subexp): Use it.
Tom Tromey [Mon, 8 Mar 2021 14:27:57 +0000 (07:27 -0700)]
Split helper functions
This splits a couple of address-of and sizeof functions, so that the
body can be reused by the (coming) new expression code.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* eval.c (evaluate_subexp_for_address_base): New function.
(evaluate_subexp_for_address): Use it.
(evaluate_subexp_for_sizeof_base): New function.
(evaluate_subexp_for_sizeof): Use it.
Tom Tromey [Mon, 8 Mar 2021 14:27:57 +0000 (07:27 -0700)]
Change parameters to rust_subscript
This changes the parameters to rust_subscript, making it more suitable
for reuse by the (coming) new expression code. In particular,
rust_subscript no longer evaluates its subexpressions. Instead, they
are passed in.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
Tom Tromey [Mon, 8 Mar 2021 14:27:57 +0000 (07:27 -0700)]
Change parameters to rust_range
This changes the parameters to rust_range, making it more suitable for
reuse by the (coming) new expression code. In particular, rust_range
no longer evaluates its subexpressions. Instead, they are passed in.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
Tom Tromey [Mon, 8 Mar 2021 14:27:57 +0000 (07:27 -0700)]
Split out eval_op_binary
This splits out a new eval_op_binary helper function. This function
can handle several different binary operations:
case BINOP_EXP:
case BINOP_MUL:
case BINOP_DIV:
case BINOP_INTDIV:
case BINOP_REM:
case BINOP_MOD:
case BINOP_LSH:
case BINOP_RSH:
case BINOP_BITWISE_AND:
case BINOP_BITWISE_IOR:
case BINOP_BITWISE_XOR:
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* eval.c (eval_op_binary): New function.
(evaluate_subexp_standard): Use it.
Mike Frysinger [Mon, 8 Mar 2021 05:30:31 +0000 (00:30 -0500)]
sim: delete unused BUILD_LIBS setting
This hasn't been initialized anywhere for years. It used to be for
passing in the path to libiberty, but that stopped happening long ago.
Delete it to simplify the build logic.
Mike Frysinger [Mon, 8 Mar 2021 03:01:47 +0000 (22:01 -0500)]
sim: igen: update options API
This local macro doesn't take any args, so adjust the API to match.
No one really noticed as this is behind code that is not normally
built, only when a dev specifically tries to compile it.
Tom Tromey [Sat, 6 Mar 2021 16:38:26 +0000 (09:38 -0700)]
Fix build bug in ada-lang.c
An earlier patch of mine introduced a build failure in ada-lang.c. A
couple of "to_string" calls were not namespace-qualified. In the
failing setup, the std string_view is being used, and so (apparently)
ADL doesn't find gdb::to_string.
Tom Tromey [Sat, 6 Mar 2021 16:26:39 +0000 (09:26 -0700)]
Avoid crash on missing dwz file
If DWARF contains a reference to a "dwz" file, but there is no
.gnu_debugaltlink section, then gdb will crash. This happens because
dwarf2_get_dwz_file will return NULL, but some callers do not expect
this.
This patch changes dwarf2_get_dwz_file so that callers can require a
dwz file. Then, it updates the callers that are attempting to process
references to the dwz file to require one.
This includes a new testcase. The dwarf.exp changes don't handle the
new forms exactly correctly -- they are only handled well enough to
let this test case complete.
gdb/ChangeLog
2021-03-06 Tom Tromey <tom@tromey.com>
Tom Tromey [Sat, 6 Mar 2021 16:26:39 +0000 (09:26 -0700)]
Create new file dwarf2/sect-names.h
This creates a new file, dwarf2/sect-names.h, and moves some
DWARF-specific type definitions from symfile.h into it.
gdb/ChangeLog
2021-03-06 Tom Tromey <tom@tromey.com>
* xcoffread.c: Include sect-names.h.
* symfile.h (struct dwarf2_section_names, struct
dwarf2_debug_sections): Move to dwarf2/sect-names.h.
* dwarf2/sect-names.h: New file, from symfile.h.
* dwarf2/read.c: Include sect-names.h.
Tom Tromey [Sat, 6 Mar 2021 16:16:59 +0000 (09:16 -0700)]
Micro-optimize abbrev reading and storage
Currently, and abbrev_info points to a separately allocated array of
attr_abbrev objects. This array is constructed in a temporary vector,
then copied to the abbrev table's obstack.
This patch changes abbrev_info to use the struct hack to store the
objects directly, and changes abbrev_table::read to avoid an extra
copy when allocating, using the "growing objects" capability of
obstacks.
This saves a bit of space, and also perhaps a little time.
2021-03-06 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_attribute): Make 'abbrev' const.
* dwarf2/abbrev.c (abbrev_table::alloc_abbrev): Remove.
(abbrev_table::read): Update.
* dwarf2/abbrev.h (struct attr_abbrev): Move earlier.
(struct abbrev_info): Reformat.
<attrs>: Now an array.
(struct abbrev_table) <alloc_abbrev>: Remove.
H.J. Lu [Sat, 6 Mar 2021 02:24:56 +0000 (18:24 -0800)]
elf/x86-64: Subtract __ImageBase for R_AMD64_IMAGEBASE
When linking Windows x86-64 relocatable object files to generate x86-64
ELF executable, we need to subtract __ImageBase, aka __executable_start,
for R_AMD64_IMAGEBASE relocation:
1. Add link_info to struct output_elf_obj_tdata to store linker info and
_bfd_get_link_info() to retrieve it.
2. Add ldelf_set_output_arch to set up link_info.
3. Add pex64_link_add_symbols to create an indirect reference to
__executable_start for __ImageBase to support R_AMD64_IMAGEBASE relocation
when adding symbols from Windows x86-64 relocatable object files to
generate x86-64 ELF executable.
4. Also subtract __ImageBase for R_AMD64_IMAGEBASE when generating x86-64
ELF executable.
bfd/
PR ld/27425
PR ld/27432
* bfd.c (_bfd_get_link_info): New function.
* elf-bfd.h (output_elf_obj_tdata): Add link_info.
(elf_link_info): New.
* libbfd-in.h (_bfd_get_link_info): New prototype.
* coff-x86_64.c (coff_amd64_reloc): Also subtract __ImageBase for
R_AMD64_IMAGEBASE when generating x86-64 ELF executable.
* pe-x86_64.c: Include "coff/internal.h" and "libcoff.h".
(pex64_link_add_symbols): New function.
(coff_bfd_link_add_symbols): New macro.
* libbfd.h: Regenerated.
Mark Wielaard [Sat, 6 Mar 2021 00:49:27 +0000 (01:49 +0100)]
Make valgrind tests more robust by adding --wait=1 to vgdb invocation
On my setup some valgrind tests failed somewhat reliably because
the target remote | vgdb command couldn't find the vgdb-pipe files
because valgrind startup hadn't finished yet.
I tried to fix this by replacing the "Memcheck, a memory error detector"
match to "TO DEBUG THIS PROCESS USING GDB: start GDB like this" which is
right before valgrind creates the vgdb-pipe files. But even that didn't
guarantee that the vgdb-pipe files were there (maybe valgrind should
print that text after it has created them?). But also not all tests
use --vgdb-error=0, so the text isn't always printed.
To make the tests reliable I added --wait=1 to the vgdb invocation.
That tells vgdb to try to find the vgdb-pipe files, and if they aren't
there yet, to wait 1 second and try again.
gdb/testsuite/ChangeLog:
* lib/valgrind.exp (vgdb_start): Add --wait=1 to vgdbcmd.
The ctf reader was modified to enter all members of an enum type,
similar to what the dwarf2 reader did, into the psymtab or gdb
won't be able to find them. In addition, the empty name checking
needed to be moved down so members of a unnamed enum were not left
out.
gdb/ChangeLog:
* ctfread.c (ctf_psymtab_add_enums): New function.
(ctf_psymtab_type_cb): call ctf_psymtab_add_enums.
Andrew Burgess [Fri, 27 Nov 2020 14:39:23 +0000 (14:39 +0000)]
gdb/riscv: write CSRs into baremetal core dumps
Use the current target description to include CSRs into the RISC-V
baremetal core dumps.
Every CSR declared in the current target description will be included
in the core dump.
It will be critical for users that they have the same target
description in use when loading the core file as was in use when
writing the core file. This should be fine if the user allows the
target description to be written into the core file.
In more detail, this commit adds a NT_RISCV_CSR note type. The
contents of this section is a series of either 4-byte (on RV32
targets), or 8-byte (on RV64 targets) values. Every CSR that is
mentioned in the current target description is written out in the
order the registers appear in the target description. As a
consequence it is critical that the exact same target description,
including the same register order, is in use when the CSRs are loaded
from the core file.
gdb/ChangeLog:
* riscv-none-tdep.c: Add 'user-regs.h' and 'target-description.h'
includes.
(riscv_csrset): New static global.
(riscv_update_csrmap): New function.
(riscv_iterate_over_regset_sections): Process CSRs.
Andrew Burgess [Mon, 15 Feb 2021 16:07:48 +0000 (16:07 +0000)]
gdb/riscv: make riscv target description names global
A later commit will need the names of the RISC-V target description
features in files other than riscv-tdep.c. This commit just makes the
names global strings that can be accessed from other riscv-*.c files.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* riscv-tdep.c (riscv_feature_name_csr): Define.
(riscv_feature_name_cpu): Define.
(riscv_feature_name_fpu): Define.
(riscv_feature_name_virtual): Define.
(riscv_xreg_feature): Use riscv_feature_name_cpu.
(riscv_freg_feature): Use riscv_feature_name_fpu.
(riscv_virtual_feature): Use riscv_feature_name_virtual.
(riscv_csr_feature): Use riscv_feature_name_csr.
* riscv-tdep.h (riscv_feature_name_csr): Declare.
As I have not yet heard if the above patch will be accepted into the
kernel or not I have set the note name string to "GDB", and the note
type to NT_RISCV_CSR.
This means that if the above patch is rejected from the kernel, and
the note type number 0x900 is assigned to some other note type, we
will still be able to distinguish between the GDB produced
NT_RISCV_CSR, and the kernel produced notes, where the name would be
set to "CORE".
bfd/ChangeLog:
* elf-bfd.h (elfcore_write_riscv_csr): Declare.
* elf.c (elfcore_grok_riscv_csr): New function.
(elfcore_grok_note): Handle NT_RISCV_CSR.
(elfcore_write_riscv_csr): New function.
(elfcore_write_register_note): Handle '.reg-riscv-csr'.
Andrew Burgess [Mon, 30 Nov 2020 12:15:08 +0000 (12:15 +0000)]
gdb/riscv: introduce bare metal core dump support
This commit adds the ability for bare metal RISC-V target to generate
core files from within GDB.
The intended use case is that a user will connect to a remote bare
metal target, debug up to some error condition, then generate a core
file in the normal way using:
(gdb) generate-core-file
This core file can then be used to revisit the state of the remote
target without having to reconnect to the remote target.
The core file creation code is split between two new files. In
elf-none-tdep.c is code for any architecture with the none
ABI (i.e. bare metal) when the BFD library is built with ELF support.
In riscv-none-tdep.c are the RISC-V specific parts. This is where the
regset and regcache_map_entry structures are defined that control how
registers are laid out in the core file. As this file could (in
theory at least) be used for a non-ELF bare metal RISC-V target, the
calls into elf-none-tdep.c are guarded with '#ifdef HAVE_ELF'.
Currently for RISC-V only the x-regs and f-regs (if present) are
written out. In future commits I plan to add support for writing out
the RISC-V CSRs.
The core dump format is based around generating an ELF containing
sections for the writable regions of memory that a user could be
using. Which regions are dumped rely on GDB's existing common core
dumping code, GDB will attempt to figure out the stack and heap as
well as copying out writable data sections as identified by the
original ELF.
Register information is added to the core dump using notes, just as it
is for Linux of FreeBSD core dumps. The note types used consist of
the 3 basic types you would expect in a OS based core dump,
NT_PRPSINFO, NT_PRSTATUS, NT_FPREGSET.
The layout of these notes differs slightly (due to field sizes)
between RV32 and RV64. Below I describe the data layout for each
note. In all cases, all padding fields should be set to zero.
Field 'fname' - null terminated string consisting of the basename of
(up to the fist 15 characters of) the executable. Any additional
space should be set to zero. If there's no executable name then
this field can be set to all zero.
Field 'psargs' - a null terminated string up to 80 characters in
length. Any additional space should be filled with zero. This
field contains the full executable path and any arguments passed
to the executable. If there's nothing sensible to write in this
field then fill it with zero.
Field 'sig' - the signal that stopped this thread. It's implementation
defined what this field actually means. Within GDB this will be
the signal number that the remote target reports as the stop
reason for this thread.
Field 'thread_is' - the thread id for this thread. It's implementation
defined what this field actually means. Within GDB this will be
thread thread-id that is assigned to each remote thread.
Field 'x_regs' - at index 0 we store the program counter, and at
indices 1 to 31 we store x-registers 1 to 31. x-register 0 is not
stored, its value is always zero anyway.
Note NT_FPREGSET is optional, its data layout is:
fpregset32_t /* For targets with 'F' extension. */
{
uint32_t f_regs[32];
uint32_t fcsr;
}
fpregset64_t /* For targets with 'D' extension . */
{
uint64_t f_regs[32];
uint32_t fcsr;
}
Field 'f_regs' - stores f-registers 0 to 31.
Field 'fcsr' - stores the fcsr CSR register, and is always 4-bytes.
The rules for ordering the notes is the same as for Linux. The
NT_PRSTATUS note must come before any other notes about additional
register sets. And for multi-threaded targets all registers for a
single thread should be grouped together. This is because only
NT_PRSTATUS includes a thread-id, all additional register notes after
a NT_PRSTATUS are assumed to belong to the same thread until a
different NT_PRSTATUS is seen.
gdb/ChangeLog:
* Makefile.in (ALL_TARGET_OBS): Add riscv-none-tdep.o.
(ALLDEPFILES): Add riscv-none-tdep.c.
* configure: Regenerate.
* configure.ac (CONFIG_OBS): Add elf-none-tdep.o when BFD has ELF
support.
* configure.tgt (riscv*-*-*): Include riscv-none-tdep.c.
* elf-none-tdep.c: New file.
* elf-none-tdep.h: New file.
* riscv-none-tdep.c: New file.
Andrew Burgess [Mon, 30 Nov 2020 12:14:38 +0000 (12:14 +0000)]
bfd/riscv: prepare to handle bare metal core dump creation
When creating a core file GDB will call the function
elfcore_write_prstatus to write out the general purpose registers
along with the pid/tid for the thread (into a prstatus structure) and
the executable name and arguments (into a prpsinfo_t structure).
However, for a bare metal RISC-V tool chain the prstatus_t and
prpsinfo_t types are not defined so the elfcore_write_prstatus
function will return NULL, preventing core file creation.
This commit provides the `elf_backend_write_core_note' hook and uses
the provided function to write out the required information.
In order to keep changes in the non bare metal tools to a minimum, the
provided backend function will itself return NULL when the prstatus_t
or pspsinfo_t types are available, the consequence of this is that the
generic code in elfcore_write_prstatus will be used just as before.
But, when prstatus_t or prpsinfo_t is not available, the new backend
function will write out the information using predefined offsets.
This new functionality will be used by a later GDB commit that will
add bare metal core dumps for RISC-V.
bfd/ChangeLog:
* elfnn-riscv.c (PRPSINFO_PR_FNAME_LENGTH): Define.
(PRPSINFO_PR_PSARGS_LENGTH): Define.
(riscv_write_core_note): New function.
(riscv_elf_grok_psinfo): Make use of two new length defines.
(elf_backend_write_core_note): Define.
projects / thirdparty / binutils-gdb.git / log
