diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-10-11 10:30:35 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-10-16 10:01:22 +0100 |
commit | 4b2f71e6c67060e2aa0d35652de80fdc1f810ce8 (patch) | |
tree | d30dd4850b674c145a86aa93bcef1b93565a3aa9 /gdb/python | |
parent | 9f9073e5b8f7828a97d6cb1e7a43c6ad1fb40a9b (diff) | |
download | gdb-4b2f71e6c67060e2aa0d35652de80fdc1f810ce8.zip gdb-4b2f71e6c67060e2aa0d35652de80fdc1f810ce8.tar.gz gdb-4b2f71e6c67060e2aa0d35652de80fdc1f810ce8.tar.bz2 |
gdb: replace architecture_changed with new_architecture observer
This commit replaces the architecture_changed observer with a
new_architecture observer.
Currently the only user of the architecture_changed observer is the
Python code, which uses this observer to register the Python unwinder
with the architecture.
The problem is that the architecture_changed observer is triggered
from inferior::set_arch(), which only sees the inferior-wide gdbarch
value. For targets that use thread-specific architectures, these
never trigger the architecture_changed observer, and so never have the
Python unwinder registered with them.
When it comes to unwinding GDB makes use of the frame's gdbarch, which
is based on the thread's regcache gdbarch, which is set in
get_thread_regcache to the value returned from
target_thread_architecture, which is not always the inferiors gdbarch
value, it might be a thread-specific gdbarch which has not passed
through inferior::set_arch().
The new_architecture observer will be triggered from
gdbarch_find_by_info, whenever a new gdbarch is created and
initialised. As GDB caches and reuses gdbarch values, we should
expect to see each new architecture trigger the new_architecture
observer just once.
After this commit, targets that make use of thread-specific
architectures should be able to make use of Python unwinders.
As I don't have access to a machine that makes use of thread-specific
architectures right now, I asked Luis to confirm that an AArch64
target that uses SVE/SME can't use the Python unwinders in threads
that are using a thread-specific architectures, and he confirmed that
this is indeed the case, see this discussion:
https://inbox.sourceware.org/gdb/87wmvsat8i.fsf@redhat.com
Tested-By: Lancelot Six <lancelot.six@amd.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Diffstat (limited to 'gdb/python')
-rw-r--r-- | gdb/python/py-unwind.c | 5 |
1 files changed, 2 insertions, 3 deletions
diff --git a/gdb/python/py-unwind.c b/gdb/python/py-unwind.c index f8b142d..ee50c51 100644 --- a/gdb/python/py-unwind.c +++ b/gdb/python/py-unwind.c @@ -945,7 +945,7 @@ static const registry<gdbarch>::key<pyuw_gdbarch_data_type> pyuw_gdbarch_data; intermediary. */ static void -pyuw_on_new_gdbarch (inferior *inf, gdbarch *newarch) +pyuw_on_new_gdbarch (gdbarch *newarch) { struct pyuw_gdbarch_data_type *data = pyuw_gdbarch_data.get (newarch); if (data == nullptr) @@ -974,8 +974,7 @@ pyuw_on_new_gdbarch (inferior *inf, gdbarch *newarch) static int CPYCHECKER_NEGATIVE_RESULT_SETS_EXCEPTION gdbpy_initialize_unwind (void) { - gdb::observers::architecture_changed.attach (pyuw_on_new_gdbarch, - "py-unwind"); + gdb::observers::new_architecture.attach (pyuw_on_new_gdbarch, "py-unwind"); if (PyType_Ready (&pending_frame_object_type) < 0) return -1; |