diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-06-01 18:30:48 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-07-03 18:02:26 +0100 |
commit | 22ed04122f2a2c566e076eac166a8dea171e8ba9 (patch) | |
tree | 665b2b10a20f70fb2bd6d8186aa87bd2db7b3b68 /gdb/python | |
parent | 0d368ae540c04d317b24679435f147751cee519a (diff) | |
download | gdb-22ed04122f2a2c566e076eac166a8dea171e8ba9.zip gdb-22ed04122f2a2c566e076eac166a8dea171e8ba9.tar.gz gdb-22ed04122f2a2c566e076eac166a8dea171e8ba9.tar.bz2 |
gdb: split inferior and thread setup when opening a core file
I noticed that in corelow.c, when a core file is opened, both the
thread and inferior setup is done in add_to_thread_list. In this
patch I propose hoisting the inferior setup out of add_to_thread_list
into core_target_open.
The only thing about this change that gave me cause for concern is
that in add_to_thread_list, we only setup the inferior after finding
the first section with a name like ".reg/NN". If we find no such
section then the inferior will never be setup.
Is this important?
Well, I don't think so. Back in core_target_open, if there is no
current thread (which there will not be if no ".reg/NN" section was
found), then we look for a thread in the current inferior. If there
are no threads (which there will not be if no ".reg/NN" is found),
then we once again setup the current inferior.
What I think this means, is that, in all cases, the current inferior
will end up being setup. By moving the inferior setup code earlier in
core_target_open and making it non-conditional, we can remove the
later code that sets up the inferior, we now know this will always
have been done.
There should be no user visible changes after this commit.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
Diffstat (limited to 'gdb/python')
0 files changed, 0 insertions, 0 deletions