Most files including gdbcmd.h currently rely on it to access things
actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make
things easy, replace all includes of gdbcmd.h with includes of
cli/cli-cmds.h. This might lead to some unused includes of
cli/cli-cmds.h, but it's harmless, and much faster than going through
the 170 or so files by hand.
Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f
Approved-By: Tom Tromey <tom@tromey.com>
Move the declarations out of defs.h, and the implementations out of
findvar.c.
I opted for a new file, because this functionality of converting
integers to bytes and vice-versa seems a bit to generic to live in
findvar.c.
Change-Id: I524858fca33901ee2150c582bac16042148d2251
Approved-By: John Baldwin <jhb@FreeBSD.org>
Now that defs.h, server.h and common-defs.h are included via the
`-include` option, it is no longer necessary for source files to include
them. Remove all the inclusions of these files I could find. Update
the generation scripts where relevant.
Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837
Approved-By: Pedro Alves <pedro@palves.net>
We currently pass frames to function by value, as `frame_info_ptr`.
This is somewhat expensive:
- the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass
by value
- the constructors and destructor link/unlink the object in the global
`frame_info_ptr::frame_list` list. This is an `intrusive_list`, so
it's not so bad: it's just assigning a few points, there's no memory
allocation as if it was `std::list`, but still it's useless to do
that over and over.
As suggested by Tom Tromey, change many function signatures to accept
`const frame_info_ptr &` instead of `frame_info_ptr`.
Some functions reassign their `frame_info_ptr` parameter, like:
void
the_func (frame_info_ptr frame)
{
for (; frame != nullptr; frame = get_prev_frame (frame))
{
...
}
}
I wondered what to do about them, do I leave them as-is or change them
(and need to introduce a separate local variable that can be
re-assigned). I opted for the later for consistency. It might not be
clear why some functions take `const frame_info_ptr &` while others take
`frame_info_ptr`. Also, if a function took a `frame_info_ptr` because
it did re-assign its parameter, I doubt that we would think to change it
to `const frame_info_ptr &` should the implementation change such that
it doesn't need to take `frame_info_ptr` anymore. It seems better to
have a simple rule and apply it everywhere.
Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0
Approved-By: Andrew Burgess <aburgess@redhat.com>
I don't like the name `target_so_ops`, because:
- The name `target` is so overloaded, and in this case it's not even
related to target_ops or anything else called "target".
- We do have an implementation that actually fetches solibs from the
target (solib_target_so_op in solib-target.c), so it's confusing for
the "base class" to be called target_something as well.
Rename to solib_ops.
Change-Id: I46a983d44e81400470e22deb09aaf26ad8a3587f
Approved-By: Tom Tromey <tom@tromey.com>
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
Since GDB now requires C++17, we don't need the internally maintained
gdb::optional implementation. This patch does the following replacing:
- gdb::optional -> std::optional
- gdb::in_place -> std::in_place
- #include "gdbsupport/gdb_optional.h" -> #include <optional>
This change has mostly been done automatically. One exception is
gdbsupport/thread-pool.* which did not use the gdb:: prefix as it
already lives in the gdb namespace.
Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
The test currently fails for IEEE 128-bit floating point types. PowerPC
supports the IBM double 128-bit floating point format and IEEE 128-bit
format. The IBM double 128-bit floating point format uses two 64-bit
floating point registers to store the 128-bit value. The IEEE 128-bit
floating point format stores the value in a single 128-bit vector-scalar
register (vsr).
The various floating point values, 32-bit float, 64-bit double, IBM double
128-bit float and IEEE 128-bit floating point numbers are all mapped to the
DWARF fpr numbers. The issue is the IEEE 128-bit floating point values are
actually stored in a vsr not the fprs. This patch changes the register
mapping for the vsrs from the fpr to the vsr registers so the value is
properly accessed by GDB. The functions rs6000_linux_register_to_value,
rs6000_linux_value_to_register, rs6000_linux_value_from_register check if
the value is an IEEE 128-bit floating point value and adjust the register
number as needed. The test in function rs6000_convert_register_p is fixed
so it is only true for floating point values.
This patch fixes three regression tests in gdb.base/store.exp.
The patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE
with no regressions.
Overview of issues fixed by the patch.
The primary issue this patch fixes is the DWARF register mapping for
Linux. The changes in ppc-linux-tdep.c fix the DWARF register mapping
issues. The register mapping issue is responsible for two of the
five regression bugs seen in gdb.base/store.exp.
Once the register mapping was fixed, an underlying issue with the unwinding
of the signal trampoline in common-code in ifrun.c was found. This
underlying bug is best described by Ulrich in the following description.
The unwinder bug shows up on platforms where the kernel uses a trampoline
to dispatch "calls to" the signal handler (not just *returns from* the
signal handler). Many platforms use a trampoline for signal return, and
that is working fine, but the only platform I'm (Ulrich) aware of that
uses a trampoline for signal handler calls is (recent kernels for)
PowerPC. I believe the rationale for using a trampoline here
is to improve performance by avoiding unbalancing of the
branch predictor's call/return stack.
However, on PowerPC the bug is dormant as well as it is hidden
by *another* bug that prevents correct unwinding out of the
signal trampoline. This is because the custom CFI for the
trampoline uses a register number (VSCR) that is not ever used
by compiler-generated CFI, and that particular register is
mapped to an invalid number by the current PowerPC DWARF mapper.
The underlying unwinder bug is exposed by the "new" regression failures
in gdb.base/sigstep.exp. These failures were previously masked by
the fact that GDB was not seeing a valid frame when it tried to unwind
the frames. The sigstep.exp test is specifically testing stepping into
a signal handler. With the correct DWARF register mapping in place,
specifically the VSCR mapping, the signal trampoline code now unwinds to a
valid frame exposing the pre-existing bug in how the signal handler on
PowerPC works. The one line change infrun.c fixes the exiting bug in
the common-code for platforms that use a trampoline to dispatch calls
to the signal handler by not stopping in the SIGTRAMP_FRAME.
Detailed description of the DWARF register mapping fix.
The PowerPC DWARF register mapping is the same for the .eh_frame and
.debug_frame on Linux. PowerPC uses different mapping for .eh_frame and
.debug_frame on other operating systems. The current GDB support for
mapping the DWARF registers in rs6000_linux_dwarf2_reg_to_regnum and
rs6000_adjust_frame_regnum file gdb/rs6000-tdep.c is not correct for Linux.
The files have some legacy mappings for spe_acc, spefscr, EV which was
removed from GCC in 2017.
This patch adds a two new functions rs6000_linux_dwarf2_reg_to_regnum,
and rs6000_linux_adjust_frame_regnum in file gdb/ppc-linux-tdep.c to handle
the DWARF register mappings on Linux. Function
rs6000_linux_dwarf2_reg_to_regnum is installed for both gdb_dwarf_to_regnum
and gdbarch_stab_reg_to_regnum since the mappings are the same.
The ppc_linux_init_abi function in gdb/ppc-linux-tdep.c is updated to
call set_gdbarch_dwarf2_reg_to_regnum map the new function
rs6000_linux_dwarf2_reg_to_regnum for the architecture. Similarly,
dwarf2_frame_set_adjust_regnum is called to map
rs6000_linux_adjust_frame_regnum into the architecture.
Additional detail on the signal handling fix.
The specific sequence of events for handling a signal on most
architectures is as follows:
1) Some code is running when a signal arrives.
2) The kernel handles the signal and dispatches to the handler.
...
However on PowerPC the sequence of events is:
1) Some code is running when a signal arrives.
2) The kernel handles the signal and dispatches to the trampoline.
3) The trampoline performs a normal function call to the handler.
...
We want the "nexti" to step into, not over, signal handlers invoked by
the kernel. This is the case for most platforms as the kernel puts a
signal trampoline frame onto the stack to handle proper return after the
handler. However, on some platforms such as PowerPC, the kernel actually
uses a trampoline to handle *invocation* of the handler. We do not
want GDB to stop in the SIGTRAMP_FRAME. The issue is fixed in function
process_event_stop_test by adding a check that the frame is not a
SIGTRAMP_FRAME to the if statement to stop in a subroutine call. This
prevents GDB from erroneously detecting the trampoline invocation as a
subroutine call.
This patch fixes two regression test failures in gdb.base/store.exp.
The patch then fixes an exposed, dormant, signal handling issue that
is exposed in the signal handling test gdb.base/sigstep.exp.
The patch has been tested on Power 8 LE/BE, Power 9 LE/BE, Power 10 with
no new regressions. Note, only two of the five failures in store.exp
are fixed. The remaining three failures are fixed in a following
patch.
Make the inferior's gdbarch field private, and add getters and setters.
This helped me by allowing putting breakpoints on set_arch to know when
the inferior's arch was set. A subsequent patch in this series also
adds more things in set_arch.
Change-Id: I0005bd1ef4cd6b612af501201cec44e457998eec
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
PowerPC supports two 128-bit floating point formats, the IBM long double
and IEEE 128-bit float. The issue is the DWARF information does not
distinguish between the two. There have been proposals of how to extend
the DWARF information as discussed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
but has not been fully implemented.
GCC introduced the _Float128 internal type as a work around for the issue.
The workaround is not transparent to GDB. The internal _Float128 type
name is printed rather then the user specified long double type. This
patch adds a new gdbarch method to allow PowerPC to detect the GCC
workaround. The workaround checks for "_Float128" name when reading the
base typedef from the die_info. If the workaround is detected, the type
and format fields from the _Float128 typedef are copied to the long
double typedef. The same is done for the complex long double typedef.
This patch fixes 74 regression test failures in
gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float 128 as the
default on GCC. It fixes one regression test failure in
gdb.base/complex-parts.exp.
The patch has been tested on Power 10 where GCC defaults to IEEE Float
128-bit and on Power 10 where GCC defaults to the IBM 128-bit float. The
patch as also been tested on X86-64 with no new regression failures.
This turns value_contents_raw, value_contents_writeable, and
value_contents_all_raw into methods on value. The remaining functions
will be changed later in the series; they were a bit trickier and so I
didn't include them in this patch.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This converts a few selected architectures to use
gdbarch_return_value_as_value rather than gdbarch_return_value. The
architectures are just the ones that I am able to test. This patch
should not introduce any behavior changes.
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
With test-case gdb.base/msym-bp-shl.exp on powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.base/msym-bp-shl.exp: debug=0: before run: break foo
info breakpoint^M
Num Type Disp Enb Address What^M
1 breakpoint keep y <MULTIPLE> ^M
1.1 y 0x00000000000008d4 <foo+12>^M
1.2 y 0x0000000000000a34 crti.S:88^M
(gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: info breakpoint
...
The problem is that the prologue skipper walks from foo@plt at 0xa28 to 0xa34:
...
0000000000000a28 <foo@plt>:
a28: c0 ff ff 4b b 9e8 <__glink_PLTresolve>
Disassembly of section .fini:
0000000000000a2c <_fini>:
a2c: 02 00 4c 3c addis r2,r12,2
a30: d4 74 42 38 addi r2,r2,29908
a34: a6 02 08 7c mflr r0
...
This is caused by ppc_elfv2_elf_make_msymbol_special which marks foo@plt as
having a local entry point, due to incorrectly accessing an asymbol struct
using a (larger) elf_symbol_type.
Fix this by simply ignoring artificial symbols in
ppc_elfv2_elf_make_msymbol_special.
Tested on powerpc64le.
Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
Reviewed-By: Carl Love <cel@us.ibm.com>
Tested-By: Carl Love <cel@us.ibm.com>
PR tdep/29814
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29814
Test gdb.reverse/pipe-reverse.exp fails on Power 10 running the fedora 36
distro. The gdb record error message is:
Process record and replay target doesn't support syscall number 317.
System call 317 on PowerPC maps to the pipe2 system call.
This patch adds support for the missing pipe2 system call for PowerPC.
Patch fixes the test failure in gdb.reverse/pipe-reverse.exp.
The patch has been tested on Power 10 with no regression failures.
Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:
internal_error (__FILE__, __LINE__, "foo %d", var);
The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability. We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.
So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.
The result is that we now should call internal_error like so:
internal_error ("foo %d", var);
Likewise for internal_warning.
The patch adjusts all calls sites. 99% of the adjustments were done
with a perl/sed script.
The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
Having two overloads of target_read_auxv that don't have the same goals
is confusing. Rename the one that reads from an explicit target_ops to
target_read_auxv_raw. Also, it occured to me that the non-raw version
could use the raw version, that reduces duplication a bit.
Change-Id: I28e5f7cecbfcacd0174d4686efb3e4a23b4ad491
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
This changes GDB to use frame_info_ptr instead of frame_info *
The substitution was done with multiple sequential `sed` commands:
sed 's/^struct frame_info;/class frame_info_ptr;/'
sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
issues in a few files, that were manually fixed.
sed 's/\<frame_info \*/frame_info_ptr /g'
sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
problems.
The changed files were then manually checked and some 'sed' changes
undone, some constructors and some gets were added, according to what
made sense, and what Tromey originally did
Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>
This changs solib_ops to be an ordinary gdbarch value and updates all
the uses. This removes a longstanding FIXME and makes the code
somewhat cleaner as well.
I built GDB for all targets on a x86-64/GNU-Linux system, and
then (accidentally) passed GDB a RISC-V binary, and asked GDB to "run"
the binary on the native target. I got this error:
(gdb) show architecture
The target architecture is set to "auto" (currently "i386").
(gdb) file /tmp/hello.rv32.exe
Reading symbols from /tmp/hello.rv32.exe...
(gdb) show architecture
The target architecture is set to "auto" (currently "riscv:rv32").
(gdb) run
Starting program: /tmp/hello.rv32.exe
../../src/gdb/i387-tdep.c:596: internal-error: i387_supply_fxsave: Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed.
What's going on here is this; initially the architecture is i386, this
is based on the default architecture, which is set based on the native
target. After loading the RISC-V executable the architecture of the
current inferior is updated based on the architecture of the
executable.
When we "run", GDB does a fork & exec, with the inferior being
controlled through ptrace. GDB sees an initial stop from the inferior
as soon as the inferior comes to life. In response to this stop GDB
ends up calling save_stop_reason (linux-nat.c), which ends up trying
to read register from the inferior, to do this we end up calling
target_ops::fetch_registers, which, for the x86-64 native target,
calls amd64_linux_nat_target::fetch_registers.
After this I eventually end up in i387_supply_fxsave, different x86
based targets will end in different functions to fetch registers, but
it doesn't really matter which function we end up in, the problem is
this line, which is repeated in many places:
i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);
The problem here is that the ARCH in this line comes from the current
inferior, which, as we discussed above, will be a RISC-V gdbarch, the
tdep field will actually be of type riscv_gdbarch_tdep, not
i386_gdbarch_tdep. After this cast we are relying on undefined
behaviour, in my case I happen to trigger an assert, but this might
not always be the case.
The thing I tried that exposed this problem was of course, trying to
start an executable of the wrong architecture on a native target. I
don't think that the correct solution for this problem is to detect,
at the point of cast, that the gdbarch_tdep object is of the wrong
type, but, I did wonder, is there a way that we could protect
ourselves from incorrectly casting the gdbarch_tdep object?
I think that there is something we can do here, and this commit is the
first step in that direction, though no actual check is added by this
commit.
This commit can be split into two parts:
(1) In gdbarch.h and arch-utils.c. In these files I have modified
gdbarch_tdep (the function) so that it now takes a template argument,
like this:
template<typename TDepType>
static inline TDepType *
gdbarch_tdep (struct gdbarch *gdbarch)
{
struct gdbarch_tdep *tdep = gdbarch_tdep_1 (gdbarch);
return static_cast<TDepType *> (tdep);
}
After this change we are no better protected, but the cast is now
done within the gdbarch_tdep function rather than at the call sites,
this leads to the second, much larger change in this commit,
(2) Everywhere gdbarch_tdep is called, we make changes like this:
- i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);
+ i386_gdbarch_tdep *tdep = gdbarch_tdep<i386_gdbarch_tdep> (arch);
There should be no functional change after this commit.
In the next commit I will build on this change to add an assertion in
gdbarch_tdep that checks we are casting to the correct type.
Some of the ioctl numbers are based on the size of kernel termios structure.
Currently the PowerPC GDB definitions are "hard coded" into the ioctl
number.
The current PowerPC values for TCGETS, TCSETS, TCSETSW and TCSETSF are
defined in gdb/ppc-linux-tdep.c as:
record_tdep->ioctl_TCGETS = 0x403c7413;
record_tdep->ioctl_TCSETS = 0x803c7414;
record_tdep->ioctl_TCSETSW = 0x803c7415;
record_tdep->ioctl_TCSETSF = 0x803c7416;
Where the termios structure size is in hex digits [5:4] as 0x3c.
The definition for the PowerPC termios structure is given in:
arch/powerpc/include/uapi/asm/termbits.h
The size of the termios data structure in this file is 0x2c not 0x3c.
This patch changes the hex digits for the size of the PowerPC termios size
in the ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF to 0x2c.
This patch also changes the hard coding to generate the number based on a
it easier to update the ioctl numbers.
It is better to rename floatformats_ia64_quad to floatformats_ieee_quad
to reflect the reality, and then we can clean up the related code.
As Tom Tromey said [1]:
These files are maintained in gcc and then imported into the
binutils-gdb repository, so any changes to them will have to
be proposed there first.
the related changes have been merged into gcc master now [2], it is time
to do it for gdb.
[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186569.html
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b2dff6b2d9d6
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions. This is done under the name
"gdb_printf". Most of this patch was written by script.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
The process record code often emits unfiltered output. In some cases,
this output ought to go to gdb_stderr (but see below). In other
cases, the output is guarded by a logging variable and so ought to go
to gdb_stdlog. This patch makes these changes.
Note that in many cases, the output to stderr is followed by a
"return -1", which is how process record indicates an error. It seems
to me that calling error here would be preferable, because, in many
cases, that's all the caller does when it sees a -1. However, I
haven't made this change.
This is part of PR gdb/7233.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
This patch fixes eight test failures on PowerPC for the test
gdb.base/break-interp.exp. The patch adds a funtion and registers it to
setup the displaced stepping for ppc-linux platform. The patch moves the
struct ppc_inferior_data to the ppc-tdep.h include file to make it visible
to the ppc-linux-tdep.c and rs6000-tdep.c files. Additionally the function
get_ppc_per_inferior is made external in ppc-tdep.h to make it visible in
both files.
Tested on Power 10 ppc64le-linux with no regressions.
I would like to be able to use non-trivial types in gdbarch_tdep types.
This is not possible at the moment (in theory), because of the one
definition rule.
To allow it, rename all gdbarch_tdep types to <arch>_gdbarch_tdep, and
make them inherit from a gdbarch_tdep base class. The inheritance is
necessary to be able to pass pointers to all these <arch>_gdbarch_tdep
objects to gdbarch_alloc, which takes a pointer to gdbarch_tdep.
These objects are never deleted through a base class pointer, so I
didn't include a virtual destructor. In the future, if gdbarch objects
deletable, I could imagine that the gdbarch_tdep objects could become
owned by the gdbarch objects, and then it would become useful to have a
virtual destructor (so that the gdbarch object can delete the owned
gdbarch_tdep object). But that's not necessary right now.
It turns out that RISC-V already has a gdbarch_tdep that is
non-default-constructible, so that provides a good motivation for this
change.
Most changes are fairly straightforward, mostly needing to add some
casts all over the place. There is however the xtensa architecture,
doing its own little weird thing to define its gdbarch_tdep. I did my
best to adapt it, but I can't test those changes.
Change-Id: Ic001903f91ddd106bd6ca09a79dabe8df2d69f3b
Add a method to set the gcc target options for the ppc64 targets.
This change sets an empty value, which allows the gcc
default values (-mcmodel=medium) be used, instead of -mcmodel=large
which is set by the default_gcc_target_options hook.
The r_ldsomap field is specific to Solaris (part of librtld_db), and
should never be accessed for Linux. glibc is planning to add a field
to support multiple namespaces. But there will be no r_ldsomap when
r_version is bumped to 2. Add linux_[ilp32|lp64]_fetch_link_map_offsets
to set r_ldsomap_offset to -1 and use them for Linux targets.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28236
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
Today, GDB only allows a single displaced stepping operation to happen
per inferior at a time. There is a single displaced stepping buffer per
inferior, whose address is fixed (obtained with
gdbarch_displaced_step_location), managed by infrun.c.
In the case of the AMD ROCm target [1] (in the context of which this
work has been done), it is typical to have thousands of threads (or
waves, in SMT terminology) executing the same code, hitting the same
breakpoint (possibly conditional) and needing to to displaced step it at
the same time. The limitation of only one displaced step executing at a
any given time becomes a real bottleneck.
To fix this bottleneck, we want to make it possible for threads of a
same inferior to execute multiple displaced steps in parallel. This
patch builds the foundation for that.
In essence, this patch moves the task of preparing a displaced step and
cleaning up after to gdbarch functions. This allows using different
schemes for allocating and managing displaced stepping buffers for
different platforms. The gdbarch decides how to assign a buffer to a
thread that needs to execute a displaced step.
On the ROCm target, we are able to allocate one displaced stepping
buffer per thread, so a thread will never have to wait to execute a
displaced step.
On Linux, the entry point of the executable if used as the displaced
stepping buffer, since we assume that this code won't get used after
startup. From what I saw (I checked with a binary generated against
glibc and musl), on AMD64 we have enough space there to fit two
displaced stepping buffers. A subsequent patch makes AMD64/Linux use
two buffers.
In addition to having multiple displaced stepping buffers, there is also
the idea of sharing displaced stepping buffers between threads. Two
threads doing displaced steps for the same PC could use the same buffer
at the same time. Two threads stepping over the same instruction (same
opcode) at two different PCs may also be able to share a displaced
stepping buffer. This is an idea for future patches, but the
architecture built by this patch is made to allow this.
Now, the implementation details. The main part of this patch is moving
the responsibility of preparing and finishing a displaced step to the
gdbarch. Before this patch, preparing a displaced step is driven by the
displaced_step_prepare_throw function. It does some calls to the
gdbarch to do some low-level operations, but the high-level logic is
there. The steps are roughly:
- Ask the gdbarch for the displaced step buffer location
- Save the existing bytes in the displaced step buffer
- Ask the gdbarch to copy the instruction into the displaced step buffer
- Set the pc of the thread to the beginning of the displaced step buffer
Similarly, the "fixup" phase, executed after the instruction was
successfully single-stepped, is driven by the infrun code (function
displaced_step_finish). The steps are roughly:
- Restore the original bytes in the displaced stepping buffer
- Ask the gdbarch to fixup the instruction result (adjust the target's
registers or memory to do as if the instruction had been executed in
its original location)
The displaced_step_inferior_state::step_thread field indicates which
thread (if any) is currently using the displaced stepping buffer, so it
is used by displaced_step_prepare_throw to check if the displaced
stepping buffer is free to use or not.
This patch defers the whole task of preparing and cleaning up after a
displaced step to the gdbarch. Two new main gdbarch methods are added,
with the following semantics:
- gdbarch_displaced_step_prepare: Prepare for the given thread to
execute a displaced step of the instruction located at its current PC.
Upon return, everything should be ready for GDB to resume the thread
(with either a single step or continue, as indicated by
gdbarch_displaced_step_hw_singlestep) to make it displaced step the
instruction.
- gdbarch_displaced_step_finish: Called when the thread stopped after
having started a displaced step. Verify if the instruction was
executed, if so apply any fixup required to compensate for the fact
that the instruction was executed at a different place than its
original pc. Release any resources that were allocated for this
displaced step. Upon return, everything should be ready for GDB to
resume the thread in its "normal" code path.
The displaced_step_prepare_throw function now pretty much just offloads
to gdbarch_displaced_step_prepare and the displaced_step_finish function
offloads to gdbarch_displaced_step_finish.
The gdbarch_displaced_step_location method is now unnecessary, so is
removed. Indeed, the core of GDB doesn't know how many displaced step
buffers there are nor where they are.
To keep the existing behavior for existing architectures, the logic that
was previously implemented in infrun.c for preparing and finishing a
displaced step is moved to displaced-stepping.c, to the
displaced_step_buffer class. Architectures are modified to implement
the new gdbarch methods using this class. The behavior is not expected
to change.
The other important change (which arises from the above) is that the
core of GDB no longer prevents concurrent displaced steps. Before this
patch, start_step_over walks the global step over chain and tries to
initiate a step over (whether it is in-line or displaced). It follows
these rules:
- if an in-line step is in progress (in any inferior), don't start any
other step over
- if a displaced step is in progress for an inferior, don't start
another displaced step for that inferior
After starting a displaced step for a given inferior, it won't start
another displaced step for that inferior.
In the new code, start_step_over simply tries to initiate step overs for
all the threads in the list. But because threads may be added back to
the global list as it iterates the global list, trying to initiate step
overs, start_step_over now starts by stealing the global queue into a
local queue and iterates on the local queue. In the typical case, each
thread will either:
- have initiated a displaced step and be resumed
- have been added back by the global step over queue by
displaced_step_prepare_throw, because the gdbarch will have returned
that there aren't enough resources (i.e. buffers) to initiate a
displaced step for that thread
Lastly, if start_step_over initiates an in-line step, it stops
iterating, and moves back whatever remaining threads it had in its local
step over queue to the global step over queue.
Two other gdbarch methods are added, to handle some slightly annoying
corner cases. They feel awkwardly specific to these cases, but I don't
see any way around them:
- gdbarch_displaced_step_copy_insn_closure_by_addr: in
arm_pc_is_thumb, arm-tdep.c wants to get the closure for a given
buffer address.
- gdbarch_displaced_step_restore_all_in_ptid: when a process forks
(at least on Linux), the address space is copied. If some displaced
step buffers were in use at the time of the fork, we need to restore
the original bytes in the child's address space.
These two adjustments are also made in infrun.c:
- prepare_for_detach: there may be multiple threads doing displaced
steps when we detach, so wait until all of them are done
- handle_inferior_event: when we handle a fork event for a given
thread, it's possible that other threads are doing a displaced step at
the same time. Make sure to restore the displaced step buffer
contents in the child for them.
[1] https://github.com/ROCm-Developer-Tools/ROCgdb
gdb/ChangeLog:
* displaced-stepping.h (struct
displaced_step_copy_insn_closure): Adjust comments.
(struct displaced_step_inferior_state) <step_thread,
step_gdbarch, step_closure, step_original, step_copy,
step_saved_copy>: Remove fields.
(struct displaced_step_thread_state): New.
(struct displaced_step_buffer): New.
* displaced-stepping.c (displaced_step_buffer::prepare): New.
(write_memory_ptid): Move from infrun.c.
(displaced_step_instruction_executed_successfully): New,
factored out of displaced_step_finish.
(displaced_step_buffer::finish): New.
(displaced_step_buffer::copy_insn_closure_by_addr): New.
(displaced_step_buffer::restore_in_ptid): New.
* gdbarch.sh (displaced_step_location): Remove.
(displaced_step_prepare, displaced_step_finish,
displaced_step_copy_insn_closure_by_addr,
displaced_step_restore_all_in_ptid): New.
* gdbarch.c: Re-generate.
* gdbarch.h: Re-generate.
* gdbthread.h (class thread_info) <displaced_step_state>: New
field.
(thread_step_over_chain_remove): New declaration.
(thread_step_over_chain_next): New declaration.
(thread_step_over_chain_length): New declaration.
* thread.c (thread_step_over_chain_remove): Make non-static.
(thread_step_over_chain_next): New.
(global_thread_step_over_chain_next): Use
thread_step_over_chain_next.
(thread_step_over_chain_length): New.
(global_thread_step_over_chain_enqueue): Add debug print.
(global_thread_step_over_chain_remove): Add debug print.
* infrun.h (get_displaced_step_copy_insn_closure_by_addr):
Remove.
* infrun.c (get_displaced_stepping_state): New.
(displaced_step_in_progress_any_inferior): Remove.
(displaced_step_in_progress_thread): Adjust.
(displaced_step_in_progress): Adjust.
(displaced_step_in_progress_any_thread): New.
(get_displaced_step_copy_insn_closure_by_addr): Remove.
(gdbarch_supports_displaced_stepping): Use
gdbarch_displaced_step_prepare_p.
(displaced_step_reset): Change parameter from inferior to
thread.
(displaced_step_prepare_throw): Implement using
gdbarch_displaced_step_prepare.
(write_memory_ptid): Move to displaced-step.c.
(displaced_step_restore): Remove.
(displaced_step_finish): Implement using
gdbarch_displaced_step_finish.
(start_step_over): Allow starting more than one displaced step.
(prepare_for_detach): Handle possibly multiple threads doing
displaced steps.
(handle_inferior_event): Handle possibility that fork event
happens while another thread displaced steps.
* linux-tdep.h (linux_displaced_step_prepare): New.
(linux_displaced_step_finish): New.
(linux_displaced_step_copy_insn_closure_by_addr): New.
(linux_displaced_step_restore_all_in_ptid): New.
(linux_init_abi): Add supports_displaced_step parameter.
* linux-tdep.c (struct linux_info) <disp_step_buf>: New field.
(linux_displaced_step_prepare): New.
(linux_displaced_step_finish): New.
(linux_displaced_step_copy_insn_closure_by_addr): New.
(linux_displaced_step_restore_all_in_ptid): New.
(linux_init_abi): Add supports_displaced_step parameter,
register displaced step methods if true.
(_initialize_linux_tdep): Register inferior_execd observer.
* amd64-linux-tdep.c (amd64_linux_init_abi_common): Add
supports_displaced_step parameter, adjust call to
linux_init_abi. Remove call to
set_gdbarch_displaced_step_location.
(amd64_linux_init_abi): Adjust call to
amd64_linux_init_abi_common.
(amd64_x32_linux_init_abi): Likewise.
* aarch64-linux-tdep.c (aarch64_linux_init_abi): Adjust call to
linux_init_abi. Remove call to
set_gdbarch_displaced_step_location.
* arm-linux-tdep.c (arm_linux_init_abi): Likewise.
* i386-linux-tdep.c (i386_linux_init_abi): Likewise.
* alpha-linux-tdep.c (alpha_linux_init_abi): Adjust call to
linux_init_abi.
* arc-linux-tdep.c (arc_linux_init_osabi): Likewise.
* bfin-linux-tdep.c (bfin_linux_init_abi): Likewise.
* cris-linux-tdep.c (cris_linux_init_abi): Likewise.
* csky-linux-tdep.c (csky_linux_init_abi): Likewise.
* frv-linux-tdep.c (frv_linux_init_abi): Likewise.
* hppa-linux-tdep.c (hppa_linux_init_abi): Likewise.
* ia64-linux-tdep.c (ia64_linux_init_abi): Likewise.
* m32r-linux-tdep.c (m32r_linux_init_abi): Likewise.
* m68k-linux-tdep.c (m68k_linux_init_abi): Likewise.
* microblaze-linux-tdep.c (microblaze_linux_init_abi): Likewise.
* mips-linux-tdep.c (mips_linux_init_abi): Likewise.
* mn10300-linux-tdep.c (am33_linux_init_osabi): Likewise.
* nios2-linux-tdep.c (nios2_linux_init_abi): Likewise.
* or1k-linux-tdep.c (or1k_linux_init_abi): Likewise.
* riscv-linux-tdep.c (riscv_linux_init_abi): Likewise.
* s390-linux-tdep.c (s390_linux_init_abi_any): Likewise.
* sh-linux-tdep.c (sh_linux_init_abi): Likewise.
* sparc-linux-tdep.c (sparc32_linux_init_abi): Likewise.
* sparc64-linux-tdep.c (sparc64_linux_init_abi): Likewise.
* tic6x-linux-tdep.c (tic6x_uclinux_init_abi): Likewise.
* tilegx-linux-tdep.c (tilegx_linux_init_abi): Likewise.
* xtensa-linux-tdep.c (xtensa_linux_init_abi): Likewise.
* ppc-linux-tdep.c (ppc_linux_init_abi): Adjust call to
linux_init_abi. Remove call to
set_gdbarch_displaced_step_location.
* arm-tdep.c (arm_pc_is_thumb): Call
gdbarch_displaced_step_copy_insn_closure_by_addr instead of
get_displaced_step_copy_insn_closure_by_addr.
* rs6000-aix-tdep.c (rs6000_aix_init_osabi): Adjust calls to
clear gdbarch methods.
* rs6000-tdep.c (struct ppc_inferior_data): New structure.
(get_ppc_per_inferior): New function.
(ppc_displaced_step_prepare): New function.
(ppc_displaced_step_finish): New function.
(ppc_displaced_step_restore_all_in_ptid): New function.
(rs6000_gdbarch_init): Register new gdbarch methods.
* s390-tdep.c (s390_gdbarch_init): Don't call
set_gdbarch_displaced_step_location, set new gdbarch methods.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-disp-step-avx.exp: Adjust pattern.
* gdb.threads/forking-threads-plus-breakpoint.exp: Likewise.
* gdb.threads/non-stop-fair-events.exp: Likewise.
Change-Id: I387cd235a442d0620ec43608fd3dc0097fcbf8c8
Remove TYPE_CODE, changing all the call sites to use type::code
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_CODE): Remove. Change all call sites to use
type::code instead.
Simon Marchi