aboutsummaryrefslogtreecommitdiff
path: root/gdb/arch-utils.c
diff options
context:
space:
mode:
authorLuis Machado <luis.machado@arm.com>2023-01-31 17:17:09 +0000
committerLuis Machado <luis.machado@arm.com>2023-10-04 16:23:40 +0100
commit7070423f17ff4756aec92aab15a88681a4f9df11 (patch)
treeddd0bd032bd48f137463beb6a79ac01412f37553 /gdb/arch-utils.c
parent147fa85a600960a1e403bbed4cb76c9d7d8ab6c5 (diff)
downloadgdb-7070423f17ff4756aec92aab15a88681a4f9df11.zip
gdb-7070423f17ff4756aec92aab15a88681a4f9df11.tar.gz
gdb-7070423f17ff4756aec92aab15a88681a4f9df11.tar.bz2
corefile/bug: Use thread-specific gdbarch when dumping register state to core files
When we have a core file generated by gdb (via the gcore command), gdb dumps the target description to a note. During loading of that core file, gdb will first try to load that saved target description. This works fine for almost all architectures. But AArch64 has a few dynamically-generated target descriptions/gdbarch depending on the vector length that was in use at the time the core file was generated. The target description gdb dumps to the core file note is the one generated at the time of attachment/startup. If, for example, the SVE vector length changed during execution, this would not reflect on the core file, as gdb would still dump the initial target description. Another issue is that the gdbarch potentially doesn't match the thread's real gdbarch, and so things like the register cache may have different formats and sizes. To address this, fetch the thread's architecture before dumping its register state. That way we will always use the correct target description/gdbarch. Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Tom Tromey <tom@tromey.com> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Diffstat (limited to 'gdb/arch-utils.c')
0 files changed, 0 insertions, 0 deletions