diff options
author | Simon Marchi <simon.marchi@efficios.com> | 2025-07-22 15:08:40 -0400 |
---|---|---|
committer | Simon Marchi <simon.marchi@efficios.com> | 2025-08-22 10:45:48 -0400 |
commit | a7ba2c42b807d1f23b2cc11598973a1c7386e379 (patch) | |
tree | efaa7d39462e8ab1889328f0ac8425f6a7ed32d6 /gdb/python | |
parent | fbb487b4510dc2cd6cf7e82df062d7e40eeb8c27 (diff) | |
download | gdb-a7ba2c42b807d1f23b2cc11598973a1c7386e379.zip gdb-a7ba2c42b807d1f23b2cc11598973a1c7386e379.tar.gz gdb-a7ba2c42b807d1f23b2cc11598973a1c7386e379.tar.bz2 |
gdb/solib-svr4: centralize fetching of default debug base
When running an inferior, solib_ops_svr4::current_sos is called very
early, at a point where the default debug base is not yet accessible.
The inferior is stopped at its entry point, before the dynamic linker
had the time to fill the DT_DEBUG slot. It only becomes available a
little bit later. In a following patch, I will want to do some action
when the debug base becomes known (namely, update the debug base in the
previously created lm_info_svr4 instances).
For this reason, add the svr4_solib_ops::default_debug_base method to
centralize where we fetch the default debug base. I will then be able
to add my code there, when detecting the debug base changes.
This patch brings the following behavior change: since all
svr4_solib_ops entry points now use svr4_solib_ops::default_debug_base
to get the debug base value, they will now all re-fetch the value from
the inferior. Previously, this was not done consistently, only in two
spots. It seems to me like it would be good to be consistent about
that, because we can't really predict which methods will get called in
which order in all scenarios.
Some internal methods still access svr4_info::default_debug_base
directly, because it is assumed that their caller would have used
svr4_solib_ops::default_debug_base, updating the value in
svr4_info::default_debug_base if necessary.
Change-Id: Ie08da34bbb3ad6fd317c0e5802c5c94d8c7d1ce5
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Diffstat (limited to 'gdb/python')
0 files changed, 0 insertions, 0 deletions