2017-10-12 02:16:34 +08:00
|
|
|
/* Target-dependent code for FreeBSD/arm.
|
|
|
|
|
|
2024-01-12 23:30:44 +08:00
|
|
|
Copyright (C) 2017-2024 Free Software Foundation, Inc.
|
2017-10-12 02:16:34 +08:00
|
|
|
|
|
|
|
|
This file is part of GDB.
|
|
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
|
|
|
|
|
|
|
2019-04-07 03:38:10 +08:00
|
|
|
#include "elf/common.h"
|
2019-07-19 21:59:10 +08:00
|
|
|
#include "target-descriptions.h"
|
|
|
|
|
#include "aarch32-tdep.h"
|
2019-04-03 10:04:24 +08:00
|
|
|
#include "arm-tdep.h"
|
2019-04-07 03:38:10 +08:00
|
|
|
#include "arm-fbsd-tdep.h"
|
2017-10-12 02:16:34 +08:00
|
|
|
#include "auxv.h"
|
|
|
|
|
#include "fbsd-tdep.h"
|
|
|
|
|
#include "gdbcore.h"
|
2022-05-04 07:05:10 +08:00
|
|
|
#include "inferior.h"
|
2017-10-12 02:16:34 +08:00
|
|
|
#include "osabi.h"
|
|
|
|
|
#include "solib-svr4.h"
|
|
|
|
|
#include "trad-frame.h"
|
|
|
|
|
#include "tramp-frame.h"
|
|
|
|
|
|
2019-01-29 02:16:58 +08:00
|
|
|
/* Register maps. */
|
|
|
|
|
|
|
|
|
|
static const struct regcache_map_entry arm_fbsd_gregmap[] =
|
|
|
|
|
{
|
|
|
|
|
{ 13, ARM_A1_REGNUM, 4 }, /* r0 ... r12 */
|
|
|
|
|
{ 1, ARM_SP_REGNUM, 4 },
|
|
|
|
|
{ 1, ARM_LR_REGNUM, 4 },
|
|
|
|
|
{ 1, ARM_PC_REGNUM, 4 },
|
|
|
|
|
{ 1, ARM_PS_REGNUM, 4 },
|
|
|
|
|
{ 0 }
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct regcache_map_entry arm_fbsd_vfpregmap[] =
|
|
|
|
|
{
|
|
|
|
|
{ 32, ARM_D0_REGNUM, 8 }, /* d0 ... d31 */
|
|
|
|
|
{ 1, ARM_FPSCR_REGNUM, 4 },
|
|
|
|
|
{ 0 }
|
|
|
|
|
};
|
|
|
|
|
|
2022-11-23 06:21:13 +08:00
|
|
|
/* Register numbers are relative to tdep->tls_regnum. */
|
|
|
|
|
|
|
|
|
|
static const struct regcache_map_entry arm_fbsd_tls_regmap[] =
|
|
|
|
|
{
|
|
|
|
|
{ 1, 0, 4 }, /* tpidruro */
|
|
|
|
|
{ 0 }
|
|
|
|
|
};
|
|
|
|
|
|
2017-10-12 02:16:34 +08:00
|
|
|
/* In a signal frame, sp points to a 'struct sigframe' which is
|
|
|
|
|
defined as:
|
|
|
|
|
|
|
|
|
|
struct sigframe {
|
|
|
|
|
siginfo_t sf_si;
|
|
|
|
|
ucontext_t sf_uc;
|
|
|
|
|
mcontext_vfp_t sf_vfp;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
ucontext_t is defined as:
|
|
|
|
|
|
|
|
|
|
struct __ucontext {
|
|
|
|
|
sigset_t uc_sigmask;
|
|
|
|
|
mcontext_t uc_mcontext;
|
|
|
|
|
...
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
mcontext_t is defined as:
|
|
|
|
|
|
|
|
|
|
struct {
|
|
|
|
|
unsigned int __gregs[17];
|
|
|
|
|
size_t mc_vfp_size;
|
|
|
|
|
void *mc_vfp_ptr;
|
|
|
|
|
...
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
mcontext_vfp_t is defined as:
|
|
|
|
|
|
|
|
|
|
struct {
|
|
|
|
|
uint64_t mcv_reg[32];
|
|
|
|
|
uint32_t mcv_fpscr;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
If the VFP state is valid, then mc_vfp_ptr will point to sf_vfp in
|
|
|
|
|
the sigframe, otherwise it is NULL. There is no non-VFP floating
|
|
|
|
|
point register state saved in the signal frame. */
|
|
|
|
|
|
|
|
|
|
#define ARM_SIGFRAME_UCONTEXT_OFFSET 64
|
|
|
|
|
#define ARM_UCONTEXT_MCONTEXT_OFFSET 16
|
|
|
|
|
#define ARM_MCONTEXT_VFP_PTR_OFFSET 72
|
|
|
|
|
|
|
|
|
|
/* Implement the "init" method of struct tramp_frame. */
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
arm_fbsd_sigframe_init (const struct tramp_frame *self,
|
gdb: pass frames as `const frame_info_ptr &`
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>
2024-02-20 02:07:47 +08:00
|
|
|
const frame_info_ptr &this_frame,
|
2017-10-12 02:16:34 +08:00
|
|
|
struct trad_frame_cache *this_cache,
|
|
|
|
|
CORE_ADDR func)
|
|
|
|
|
{
|
|
|
|
|
struct gdbarch *gdbarch = get_frame_arch (this_frame);
|
|
|
|
|
enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
|
|
|
|
|
CORE_ADDR sp = get_frame_register_unsigned (this_frame, ARM_SP_REGNUM);
|
|
|
|
|
CORE_ADDR mcontext_addr = (sp
|
|
|
|
|
+ ARM_SIGFRAME_UCONTEXT_OFFSET
|
|
|
|
|
+ ARM_UCONTEXT_MCONTEXT_OFFSET);
|
|
|
|
|
ULONGEST mcontext_vfp_addr;
|
|
|
|
|
|
2019-01-29 02:16:58 +08:00
|
|
|
trad_frame_set_reg_regmap (this_cache, arm_fbsd_gregmap, mcontext_addr,
|
|
|
|
|
regcache_map_entry_size (arm_fbsd_gregmap));
|
2017-10-12 02:16:34 +08:00
|
|
|
|
|
|
|
|
if (safe_read_memory_unsigned_integer (mcontext_addr
|
|
|
|
|
+ ARM_MCONTEXT_VFP_PTR_OFFSET, 4,
|
|
|
|
|
byte_order,
|
|
|
|
|
&mcontext_vfp_addr)
|
|
|
|
|
&& mcontext_vfp_addr != 0)
|
2019-01-29 02:16:58 +08:00
|
|
|
trad_frame_set_reg_regmap (this_cache, arm_fbsd_vfpregmap, mcontext_vfp_addr,
|
|
|
|
|
regcache_map_entry_size (arm_fbsd_vfpregmap));
|
2017-10-12 02:16:34 +08:00
|
|
|
|
|
|
|
|
trad_frame_set_id (this_cache, frame_id_build (sp, func));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const struct tramp_frame arm_fbsd_sigframe =
|
|
|
|
|
{
|
|
|
|
|
SIGTRAMP_FRAME,
|
|
|
|
|
4,
|
|
|
|
|
{
|
2018-08-08 03:04:05 +08:00
|
|
|
{0xe1a0000d, ULONGEST_MAX}, /* mov r0, sp */
|
|
|
|
|
{0xe2800040, ULONGEST_MAX}, /* add r0, r0, #SIGF_UC */
|
|
|
|
|
{0xe59f700c, ULONGEST_MAX}, /* ldr r7, [pc, #12] */
|
|
|
|
|
{0xef0001a1, ULONGEST_MAX}, /* swi SYS_sigreturn */
|
|
|
|
|
{TRAMP_SENTINEL_INSN, ULONGEST_MAX}
|
2017-10-12 02:16:34 +08:00
|
|
|
},
|
|
|
|
|
arm_fbsd_sigframe_init
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Register set definitions. */
|
|
|
|
|
|
|
|
|
|
const struct regset arm_fbsd_gregset =
|
|
|
|
|
{
|
|
|
|
|
arm_fbsd_gregmap,
|
|
|
|
|
regcache_supply_regset, regcache_collect_regset
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
const struct regset arm_fbsd_vfpregset =
|
|
|
|
|
{
|
|
|
|
|
arm_fbsd_vfpregmap,
|
|
|
|
|
regcache_supply_regset, regcache_collect_regset
|
|
|
|
|
};
|
|
|
|
|
|
2022-11-23 06:21:13 +08:00
|
|
|
static void
|
|
|
|
|
arm_fbsd_supply_tls_regset (const struct regset *regset,
|
|
|
|
|
struct regcache *regcache,
|
|
|
|
|
int regnum, const void *buf, size_t size)
|
|
|
|
|
{
|
|
|
|
|
struct gdbarch *gdbarch = regcache->arch ();
|
|
|
|
|
arm_gdbarch_tdep *tdep = gdbarch_tdep<arm_gdbarch_tdep> (gdbarch);
|
|
|
|
|
|
|
|
|
|
regcache->supply_regset (regset, tdep->tls_regnum, regnum, buf, size);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
arm_fbsd_collect_tls_regset (const struct regset *regset,
|
|
|
|
|
const struct regcache *regcache,
|
|
|
|
|
int regnum, void *buf, size_t size)
|
|
|
|
|
{
|
|
|
|
|
struct gdbarch *gdbarch = regcache->arch ();
|
|
|
|
|
arm_gdbarch_tdep *tdep = gdbarch_tdep<arm_gdbarch_tdep> (gdbarch);
|
|
|
|
|
|
|
|
|
|
regcache->collect_regset (regset, tdep->tls_regnum, regnum, buf, size);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const struct regset arm_fbsd_tls_regset =
|
|
|
|
|
{
|
|
|
|
|
arm_fbsd_tls_regmap,
|
|
|
|
|
arm_fbsd_supply_tls_regset, arm_fbsd_collect_tls_regset
|
|
|
|
|
};
|
|
|
|
|
|
2020-01-23 22:52:05 +08:00
|
|
|
/* Implement the "iterate_over_regset_sections" gdbarch method. */
|
2017-10-12 02:16:34 +08:00
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
arm_fbsd_iterate_over_regset_sections (struct gdbarch *gdbarch,
|
|
|
|
|
iterate_over_regset_sections_cb *cb,
|
|
|
|
|
void *cb_data,
|
|
|
|
|
const struct regcache *regcache)
|
|
|
|
|
{
|
gdb: move the type cast into gdbarch_tdep
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.
2022-05-19 20:20:17 +08:00
|
|
|
arm_gdbarch_tdep *tdep = gdbarch_tdep<arm_gdbarch_tdep> (gdbarch);
|
2017-10-12 02:16:34 +08:00
|
|
|
|
2018-08-13 17:04:11 +08:00
|
|
|
cb (".reg", ARM_FBSD_SIZEOF_GREGSET, ARM_FBSD_SIZEOF_GREGSET,
|
|
|
|
|
&arm_fbsd_gregset, NULL, cb_data);
|
2017-10-12 02:16:34 +08:00
|
|
|
|
2022-05-04 07:05:10 +08:00
|
|
|
if (tdep->tls_regnum > 0)
|
2022-11-23 06:21:13 +08:00
|
|
|
cb (".reg-aarch-tls", ARM_FBSD_SIZEOF_TLSREGSET, ARM_FBSD_SIZEOF_TLSREGSET,
|
|
|
|
|
&arm_fbsd_tls_regset, NULL, cb_data);
|
2022-05-04 07:05:10 +08:00
|
|
|
|
2017-10-12 02:16:34 +08:00
|
|
|
/* While FreeBSD/arm cores do contain a NT_FPREGSET / ".reg2"
|
|
|
|
|
register set, it is not populated with register values by the
|
|
|
|
|
kernel but just contains all zeroes. */
|
|
|
|
|
if (tdep->vfp_register_count > 0)
|
2018-08-13 17:04:11 +08:00
|
|
|
cb (".reg-arm-vfp", ARM_FBSD_SIZEOF_VFPREGSET, ARM_FBSD_SIZEOF_VFPREGSET,
|
|
|
|
|
&arm_fbsd_vfpregset, "VFP floating-point", cb_data);
|
2017-10-12 02:16:34 +08:00
|
|
|
}
|
|
|
|
|
|
gdb: fix auxv caching
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
2022-09-30 04:14:40 +08:00
|
|
|
/* See arm-fbsd-tdep.h. */
|
2017-10-12 02:16:34 +08:00
|
|
|
|
|
|
|
|
const struct target_desc *
|
2023-10-13 17:27:48 +08:00
|
|
|
arm_fbsd_read_description_auxv (const std::optional<gdb::byte_vector> &auxv,
|
gdb: fix auxv caching
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
2022-09-30 04:14:40 +08:00
|
|
|
target_ops *target, gdbarch *gdbarch, bool tls)
|
2017-10-12 02:16:34 +08:00
|
|
|
{
|
|
|
|
|
CORE_ADDR arm_hwcap = 0;
|
|
|
|
|
|
gdb: fix auxv caching
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
2022-09-30 04:14:40 +08:00
|
|
|
if (!auxv.has_value ()
|
|
|
|
|
|| target_auxv_search (*auxv, target, gdbarch, AT_FREEBSD_HWCAP,
|
|
|
|
|
&arm_hwcap) != 1)
|
2022-05-04 07:05:10 +08:00
|
|
|
return arm_read_description (ARM_FP_TYPE_NONE, tls);
|
2017-10-12 02:16:34 +08:00
|
|
|
|
|
|
|
|
if (arm_hwcap & HWCAP_VFP)
|
|
|
|
|
{
|
|
|
|
|
if (arm_hwcap & HWCAP_NEON)
|
gdb/arm: Remove tpidruro register from non-FreeBSD target descriptions
Commit 92d48a1e4eac ("Add an arm-tls feature which includes the tpidruro
register from CP15.") introduced the org.gnu.gdb.arm.tls feature, which
adds the tpidruro register, and unconditionally enabled it in
aarch32_create_target_description.
In Linux, the tpidruro register isn't available via ptrace in the 32-bit
kernel but it is available for an aarch32 program running under an arm64
kernel via the ptrace compat interface. This isn't currently implemented
however, which causes GDB on arm-linux with 64-bit kernel to list the
register but show it as unavailable, as reported by Tom de Vries:
$ gdb -q -batch a.out -ex start -ex 'p $tpidruro'
Temporary breakpoint 1 at 0x512
Temporary breakpoint 1, 0xaaaaa512 in main ()
$1 = <unavailable>
Simon Marchi then clarified:
> The only time we should be seeing some "unavailable" registers or memory
> is in the context of tracepoints, for things that are not collected.
> Seeing an unavailable register here is a sign that something is not
> right.
Therefore, disable the TLS feature in aarch32 target descriptions for Linux
and NetBSD targets (the latter also doesn't seem to support accessing
tpidruro either, based on a quick look at arm-netbsd-nat.c).
This patch fixes the following tests:
Running gdb.base/inline-frame-cycle-unwind.exp ...
FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 3: backtrace when the unwind is broken at frame 3
FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: backtrace when the unwind is broken at frame 5
FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1
Tested with Ubuntu 22.04.3 on armv8l-linux-gnueabihf in native,
native-gdbserver and native-extended-gdbserver targets with no regressions.
PR tdep/31418
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31418
Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-02-27 06:11:45 +08:00
|
|
|
return aarch32_read_description (tls);
|
2017-10-12 02:16:34 +08:00
|
|
|
else if ((arm_hwcap & (HWCAP_VFPv3 | HWCAP_VFPD32))
|
2021-05-28 03:01:28 +08:00
|
|
|
== (HWCAP_VFPv3 | HWCAP_VFPD32))
|
2022-05-04 07:05:10 +08:00
|
|
|
return arm_read_description (ARM_FP_TYPE_VFPV3, tls);
|
2017-10-12 02:16:34 +08:00
|
|
|
else
|
2022-05-04 07:05:10 +08:00
|
|
|
return arm_read_description (ARM_FP_TYPE_VFPV2, tls);
|
2017-10-12 02:16:34 +08:00
|
|
|
}
|
|
|
|
|
|
2022-05-04 07:05:10 +08:00
|
|
|
return arm_read_description (ARM_FP_TYPE_NONE, tls);
|
2017-10-12 02:16:34 +08:00
|
|
|
}
|
|
|
|
|
|
gdb: fix auxv caching
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
2022-09-30 04:14:40 +08:00
|
|
|
/* See arm-fbsd-tdep.h. */
|
|
|
|
|
|
|
|
|
|
const struct target_desc *
|
|
|
|
|
arm_fbsd_read_description_auxv (bool tls)
|
|
|
|
|
{
|
2023-10-13 17:27:48 +08:00
|
|
|
const std::optional<gdb::byte_vector> &auxv = target_read_auxv ();
|
gdb: fix auxv caching
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
2022-09-30 04:14:40 +08:00
|
|
|
return arm_fbsd_read_description_auxv (auxv,
|
|
|
|
|
current_inferior ()->top_target (),
|
2023-09-30 02:24:35 +08:00
|
|
|
current_inferior ()->arch (),
|
gdb: fix auxv caching
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
2022-09-30 04:14:40 +08:00
|
|
|
tls);
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-12 02:16:34 +08:00
|
|
|
/* Implement the "core_read_description" gdbarch method. */
|
|
|
|
|
|
|
|
|
|
static const struct target_desc *
|
|
|
|
|
arm_fbsd_core_read_description (struct gdbarch *gdbarch,
|
|
|
|
|
struct target_ops *target,
|
|
|
|
|
bfd *abfd)
|
|
|
|
|
{
|
2022-05-04 07:05:10 +08:00
|
|
|
asection *tls = bfd_get_section_by_name (abfd, ".reg-aarch-tls");
|
|
|
|
|
|
2023-10-13 17:27:48 +08:00
|
|
|
std::optional<gdb::byte_vector> auxv = target_read_auxv_raw (target);
|
gdb: fix auxv caching
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
2022-09-30 04:14:40 +08:00
|
|
|
return arm_fbsd_read_description_auxv (auxv, target, gdbarch, tls != nullptr);
|
2017-10-12 02:16:34 +08:00
|
|
|
}
|
|
|
|
|
|
2022-05-04 07:05:10 +08:00
|
|
|
/* Implement the get_thread_local_address gdbarch method. */
|
|
|
|
|
|
|
|
|
|
static CORE_ADDR
|
|
|
|
|
arm_fbsd_get_thread_local_address (struct gdbarch *gdbarch, ptid_t ptid,
|
|
|
|
|
CORE_ADDR lm_addr, CORE_ADDR offset)
|
|
|
|
|
{
|
gdb: move the type cast into gdbarch_tdep
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.
2022-05-19 20:20:17 +08:00
|
|
|
arm_gdbarch_tdep *tdep = gdbarch_tdep<arm_gdbarch_tdep> (gdbarch);
|
gdb: remove regcache's address space
While looking at the regcache code, I noticed that the address space
(passed to regcache when constructing it, and available through
regcache::aspace) wasn't relevant for the regcache itself. Callers of
regcache::aspace use that method because it appears to be a convenient
way of getting the address space for a thread, if you already have the
regcache. But there is always another way to get the address space, as
the callers pretty much always know which thread they are dealing with.
The regcache code itself doesn't use the address space.
This patch removes anything related to address_space from the regcache
code, and updates callers to get it from the thread in context. This
removes a bit of unnecessary complexity from the regcache code.
The current get_thread_arch_regcache function gets an address_space for
the given thread using the target_thread_address_space function (which
calls the target_ops::thread_address_space method). This suggest that
there might have been the intention of supporting per-thread address
spaces. But digging through the history, I did not find any such case.
Maybe this method was just added because we needed a way to get an
address space from a ptid (because constructing a regcache required an
address space), and this seemed like the right way to do it, I don't
know.
The only implementations of thread_address_space and
process_stratum_target::thread_address_space and
linux_nat_target::thread_address_space, which essentially just return
the inferior's address space. And thread_address_space is only used in
the current get_thread_arch_regcache, which gets removed. So, I think
that the thread_address_space target method can be removed, and we can
assume that it's fine to use the inferior's address space everywhere.
Callers of regcache::aspace are updated to get the address space from
the relevant inferior, either using some context they already know
about, or in last resort using the current global context.
So, to summarize:
- remove everything in regcache related to address spaces
- in particular, remove get_thread_arch_regcache, and rename
get_thread_arch_aspace_regcache to get_thread_arch_regcache
- remove target_ops::thread_address_space, and
target_thread_address_space
- adjust all users of regcache::aspace to get the address space another
way
Change-Id: I04fd41b22c83fe486522af7851c75bcfb31c88c7
2023-11-18 03:55:58 +08:00
|
|
|
regcache *regcache
|
|
|
|
|
= get_thread_arch_regcache (current_inferior (), ptid, gdbarch);
|
2022-05-04 07:05:10 +08:00
|
|
|
|
|
|
|
|
target_fetch_registers (regcache, tdep->tls_regnum);
|
|
|
|
|
|
|
|
|
|
ULONGEST tpidruro;
|
|
|
|
|
if (regcache->cooked_read (tdep->tls_regnum, &tpidruro) != REG_VALID)
|
|
|
|
|
error (_("Unable to fetch %%tpidruro"));
|
|
|
|
|
|
|
|
|
|
/* %tpidruro points to the TCB whose first member is the dtv
|
|
|
|
|
pointer. */
|
|
|
|
|
CORE_ADDR dtv_addr = tpidruro;
|
|
|
|
|
return fbsd_get_thread_local_address (gdbarch, dtv_addr, lm_addr, offset);
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-12 02:16:34 +08:00
|
|
|
/* Implement the 'init_osabi' method of struct gdb_osabi_handler. */
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
arm_fbsd_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
|
|
|
|
|
{
|
gdb: move the type cast into gdbarch_tdep
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.
2022-05-19 20:20:17 +08:00
|
|
|
arm_gdbarch_tdep *tdep = gdbarch_tdep<arm_gdbarch_tdep> (gdbarch);
|
2017-10-12 02:16:34 +08:00
|
|
|
|
|
|
|
|
/* Generic FreeBSD support. */
|
|
|
|
|
fbsd_init_abi (info, gdbarch);
|
|
|
|
|
|
|
|
|
|
if (tdep->fp_model == ARM_FLOAT_AUTO)
|
|
|
|
|
tdep->fp_model = ARM_FLOAT_SOFT_VFP;
|
|
|
|
|
|
|
|
|
|
tramp_frame_prepend_unwinder (gdbarch, &arm_fbsd_sigframe);
|
|
|
|
|
|
|
|
|
|
set_solib_svr4_fetch_link_map_offsets
|
|
|
|
|
(gdbarch, svr4_ilp32_fetch_link_map_offsets);
|
|
|
|
|
|
|
|
|
|
tdep->jb_pc = 24;
|
|
|
|
|
tdep->jb_elt_size = 4;
|
|
|
|
|
|
|
|
|
|
set_gdbarch_iterate_over_regset_sections
|
|
|
|
|
(gdbarch, arm_fbsd_iterate_over_regset_sections);
|
|
|
|
|
set_gdbarch_core_read_description (gdbarch, arm_fbsd_core_read_description);
|
|
|
|
|
|
2022-05-04 07:05:10 +08:00
|
|
|
if (tdep->tls_regnum > 0)
|
|
|
|
|
{
|
|
|
|
|
set_gdbarch_fetch_tls_load_module_address (gdbarch,
|
|
|
|
|
svr4_fetch_objfile_link_map);
|
|
|
|
|
set_gdbarch_get_thread_local_address (gdbarch,
|
|
|
|
|
arm_fbsd_get_thread_local_address);
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-12 02:16:34 +08:00
|
|
|
/* Single stepping. */
|
|
|
|
|
set_gdbarch_software_single_step (gdbarch, arm_software_single_step);
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-14 03:01:38 +08:00
|
|
|
void _initialize_arm_fbsd_tdep ();
|
2017-10-12 02:16:34 +08:00
|
|
|
void
|
2020-01-14 03:01:38 +08:00
|
|
|
_initialize_arm_fbsd_tdep ()
|
2017-10-12 02:16:34 +08:00
|
|
|
{
|
|
|
|
|
gdbarch_register_osabi (bfd_arch_arm, 0, GDB_OSABI_FREEBSD,
|
|
|
|
|
arm_fbsd_init_abi);
|
|
|
|
|
}
|
