* [PATCH] gdb/solib-svr4: use program space from solib in find_debug_base_for_solib
@ 2025-07-09 14:18 Simon Marchi
2025-07-10 2:44 ` Kevin Buettner
0 siblings, 1 reply; 3+ messages in thread
From: Simon Marchi @ 2025-07-09 14:18 UTC (permalink / raw)
To: gdb-patches; +Cc: Simon Marchi
Instead of using the current global program space, I think it makes
sense to fetch the program space from the solib. The comment for
solib::objfile indicates that it may be nullptr (which is true), but in
this case, the callers (all in
svr4_iterate_over_objfiles_in_search_order) find the solib from an
objfile, so we know that solib::objfile (the link in the opposite
direction) is set for these solibs at this point.
Change-Id: I75037d0b2c39ab1b3a3792432be134e200438efe
---
gdb/solib-svr4.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index 9b4cabfd5f4b..e45425438790 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -3582,7 +3582,10 @@ find_debug_base_for_solib (const solib *solib)
if (solib == nullptr)
return 0;
- svr4_info *info = get_svr4_info (current_program_space);
+ /* This is always called for solibs with an associated objfile. */
+ gdb_assert (solib->objfile != nullptr);
+
+ svr4_info *info = get_svr4_info (solib->objfile->pspace ());
gdb_assert (info != nullptr);
auto *lm_info
base-commit: 61be4420118b4039b80894ff57ad25f063218bfe
--
2.50.1
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] gdb/solib-svr4: use program space from solib in find_debug_base_for_solib
2025-07-09 14:18 [PATCH] gdb/solib-svr4: use program space from solib in find_debug_base_for_solib Simon Marchi
@ 2025-07-10 2:44 ` Kevin Buettner
2025-07-11 15:24 ` Simon Marchi
0 siblings, 1 reply; 3+ messages in thread
From: Kevin Buettner @ 2025-07-10 2:44 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb-patches
On Wed, 9 Jul 2025 10:18:46 -0400
Simon Marchi <simon.marchi@efficios.com> wrote:
> Instead of using the current global program space, I think it makes
> sense to fetch the program space from the solib. The comment for
> solib::objfile indicates that it may be nullptr (which is true), but in
> this case, the callers (all in
> svr4_iterate_over_objfiles_in_search_order) find the solib from an
> objfile, so we know that solib::objfile (the link in the opposite
> direction) is set for these solibs at this point.
Looks right to me.
Approved-by: Kevin Buettner <kevinb@redhat.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] gdb/solib-svr4: use program space from solib in find_debug_base_for_solib
2025-07-10 2:44 ` Kevin Buettner
@ 2025-07-11 15:24 ` Simon Marchi
0 siblings, 0 replies; 3+ messages in thread
From: Simon Marchi @ 2025-07-11 15:24 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
On 7/9/25 10:44 PM, Kevin Buettner wrote:
> On Wed, 9 Jul 2025 10:18:46 -0400
> Simon Marchi <simon.marchi@efficios.com> wrote:
>
>> Instead of using the current global program space, I think it makes
>> sense to fetch the program space from the solib. The comment for
>> solib::objfile indicates that it may be nullptr (which is true), but in
>> this case, the callers (all in
>> svr4_iterate_over_objfiles_in_search_order) find the solib from an
>> objfile, so we know that solib::objfile (the link in the opposite
>> direction) is set for these solibs at this point.
>
> Looks right to me.
>
> Approved-by: Kevin Buettner <kevinb@redhat.com>
>
Thanks, pushed.
Simon
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-07-11 15:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-07-09 14:18 [PATCH] gdb/solib-svr4: use program space from solib in find_debug_base_for_solib Simon Marchi
2025-07-10 2:44 ` Kevin Buettner
2025-07-11 15:24 ` Simon Marchi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox