[PATCH][fix the buildbot] gdb/solib-svr4: update default debug base in svr4_solib_ops::current_sos

[PATCH][fix the buildbot] gdb/solib-svr4: update default debug base in svr4_solib_ops::current_sos

[simon.marchi]

From: Simon Marchi <simon.marchi@polymtl.ca>

Commit d33a66a31134 ("gdb/solib-svr4: fix wrong namespace id for dynamic
linker") regressed test gdb.base/break-probes.exp with the native-gdbserver
board:

    Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/break-probes.exp ...
    FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited)
    FAIL: gdb.base/break-probes.exp: call (int) foo(23)

In the logs, we see this:

    Stopped due to shared library event:
      Inferior unloaded target:/lib64/ld-linux-x86-64.so.2
      Inferior loaded target:/lib64/ld-linux-x86-64.so.2

When we should see this:

    Stopped due to shared library event (no libraries added or removed)

In the unexpected output, GDB claims that the inferior unloaded and then
loaded the dynamic linker.  This is obviously not true.

Commit d33a66a31134 changed the svr4_same function to consider the debug
bases the solibs come from.  Two solibs with the same inferior address but
different debug base (such as the multiple solibs representing the dynamic
linker in all the namespaces) now compare unequal.

That commit also introduced a mechanism to update the debug base of an
existing solib (more precisely, field lm_info_svr4::debug_base) when that
value becomes known.  The solib for the dynamic linker view in the default
namespace starts with a debug base of 0, and is then changed to have the
real debug base address later on.

With the particular code path taken when connecting to a remote target,
nothing triggers the update of the debug base of the dynamic linker solib
initially created with a debug base of 0.  So when
svr4_solib_ops::current_sos returns a list with an solib for the dynamic
linker with the real debug base value, the core sees this as an unload and
a load.

This happens specifically when debuggin remotely, because,
svr4_solib_ops::current_sos_direct takes the "using_xfer" branch, which
doesn't do any svr4_solib_ops::default_debug_base call.  In local, we don't
take that branch, which leads us to a call to default_debug_base.

The way I propose to fix it is to add a call to
svr4_solib_ops::default_debug_base at the beginning of
svr4_solib_ops::current_sos.  The rationale to put it there is that if the
core is requesting a fresh list of libraries, and then compare that list
with what it had previously, then we better make sure that the core's list
has received the debug base update, if one is needed.

Change-Id: If09c5a7b3d956e18d4b9514466226267c85f12a6
---
 gdb/solib-svr4.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index 635e52a19877..58432b69a5d5 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -1512,6 +1512,15 @@ owning_intrusive_list<solib>
 svr4_solib_ops::current_sos () const
 {
   svr4_info *info = get_svr4_info (current_program_space);
+
+  /* Call this for the side-effect of updating the debug base in existing
+     solibs' lm_info_svr4, if needed.  It is possible for the core to have
+     an solib with a stale lm_info_svr4::debug_base.  In that case, we are
+     about to return the same solib, but with an updated debug_base.  If we
+     didn't do this call, then it would appear as two different libraries to
+     the core, and it would appear as a spurious unload / load.  */
+  this->default_debug_base (info);
+
   owning_intrusive_list<solib> sos = this->current_sos_1 (info);
   struct mem_range vsyscall_range;
 

base-commit: 7a8821ff0e1badeaa284f6a6ff0b79b8e1fe5237
-- 
2.50.1

Re: [PATCH][fix the buildbot] gdb/solib-svr4: update default debug base in svr4_solib_ops::current_sos

[Kevin Buettner]

On Fri, 29 Aug 2025 16:05:27 -0400
simon.marchi@polymtl.ca wrote:

> From: Simon Marchi <simon.marchi@polymtl.ca>
> 
> Commit d33a66a31134 ("gdb/solib-svr4: fix wrong namespace id for dynamic
> linker") regressed test gdb.base/break-probes.exp with the native-gdbserver
> board:
> 
>     Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/break-probes.exp ...
>     FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited)
>     FAIL: gdb.base/break-probes.exp: call (int) foo(23)
> 
> In the logs, we see this:
> 
>     Stopped due to shared library event:
>       Inferior unloaded target:/lib64/ld-linux-x86-64.so.2
>       Inferior loaded target:/lib64/ld-linux-x86-64.so.2
> 
> When we should see this:
> 
>     Stopped due to shared library event (no libraries added or removed)
> 
> In the unexpected output, GDB claims that the inferior unloaded and then
> loaded the dynamic linker.  This is obviously not true.
> 
> Commit d33a66a31134 changed the svr4_same function to consider the debug
> bases the solibs come from.  Two solibs with the same inferior address but
> different debug base (such as the multiple solibs representing the dynamic
> linker in all the namespaces) now compare unequal.
> 
> That commit also introduced a mechanism to update the debug base of an
> existing solib (more precisely, field lm_info_svr4::debug_base) when that
> value becomes known.  The solib for the dynamic linker view in the default
> namespace starts with a debug base of 0, and is then changed to have the
> real debug base address later on.
> 
> With the particular code path taken when connecting to a remote target,
> nothing triggers the update of the debug base of the dynamic linker solib
> initially created with a debug base of 0.  So when
> svr4_solib_ops::current_sos returns a list with an solib for the dynamic
> linker with the real debug base value, the core sees this as an unload and
> a load.
> 
> This happens specifically when debuggin remotely, because,
> svr4_solib_ops::current_sos_direct takes the "using_xfer" branch, which
> doesn't do any svr4_solib_ops::default_debug_base call.  In local, we don't
> take that branch, which leads us to a call to default_debug_base.
> 
> The way I propose to fix it is to add a call to
> svr4_solib_ops::default_debug_base at the beginning of
> svr4_solib_ops::current_sos.  The rationale to put it there is that if the
> core is requesting a fresh list of libraries, and then compare that list
> with what it had previously, then we better make sure that the core's list
> has received the debug base update, if one is needed.
> 
> Change-Id: If09c5a7b3d956e18d4b9514466226267c85f12a6
> ---
>  gdb/solib-svr4.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
> index 635e52a19877..58432b69a5d5 100644
> --- a/gdb/solib-svr4.c
> +++ b/gdb/solib-svr4.c
> @@ -1512,6 +1512,15 @@ owning_intrusive_list<solib>
>  svr4_solib_ops::current_sos () const
>  {
>    svr4_info *info = get_svr4_info (current_program_space);
> +
> +  /* Call this for the side-effect of updating the debug base in existing
> +     solibs' lm_info_svr4, if needed.  It is possible for the core to have
> +     an solib with a stale lm_info_svr4::debug_base.  In that case, we are
> +     about to return the same solib, but with an updated debug_base.  If we
> +     didn't do this call, then it would appear as two different libraries to
> +     the core, and it would appear as a spurious unload / load.  */
> +  this->default_debug_base (info);
> +
>    owning_intrusive_list<solib> sos = this->current_sos_1 (info);
>    struct mem_range vsyscall_range;
>  

LGTM.

Approved-by: Kevin Buettner <kevinb@redhat.com>

Re: [PATCH][fix the buildbot] gdb/solib-svr4: update default debug base in svr4_solib_ops::current_sos

[Simon Marchi]

On 2025-08-29 23:50, Kevin Buettner wrote:
> On Fri, 29 Aug 2025 16:05:27 -0400
> simon.marchi@polymtl.ca wrote:
> 
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>>
>> Commit d33a66a31134 ("gdb/solib-svr4: fix wrong namespace id for dynamic
>> linker") regressed test gdb.base/break-probes.exp with the native-gdbserver
>> board:
>>
>>     Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/break-probes.exp ...
>>     FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited)
>>     FAIL: gdb.base/break-probes.exp: call (int) foo(23)
>>
>> In the logs, we see this:
>>
>>     Stopped due to shared library event:
>>       Inferior unloaded target:/lib64/ld-linux-x86-64.so.2
>>       Inferior loaded target:/lib64/ld-linux-x86-64.so.2
>>
>> When we should see this:
>>
>>     Stopped due to shared library event (no libraries added or removed)
>>
>> In the unexpected output, GDB claims that the inferior unloaded and then
>> loaded the dynamic linker.  This is obviously not true.
>>
>> Commit d33a66a31134 changed the svr4_same function to consider the debug
>> bases the solibs come from.  Two solibs with the same inferior address but
>> different debug base (such as the multiple solibs representing the dynamic
>> linker in all the namespaces) now compare unequal.
>>
>> That commit also introduced a mechanism to update the debug base of an
>> existing solib (more precisely, field lm_info_svr4::debug_base) when that
>> value becomes known.  The solib for the dynamic linker view in the default
>> namespace starts with a debug base of 0, and is then changed to have the
>> real debug base address later on.
>>
>> With the particular code path taken when connecting to a remote target,
>> nothing triggers the update of the debug base of the dynamic linker solib
>> initially created with a debug base of 0.  So when
>> svr4_solib_ops::current_sos returns a list with an solib for the dynamic
>> linker with the real debug base value, the core sees this as an unload and
>> a load.
>>
>> This happens specifically when debuggin remotely, because,
>> svr4_solib_ops::current_sos_direct takes the "using_xfer" branch, which
>> doesn't do any svr4_solib_ops::default_debug_base call.  In local, we don't
>> take that branch, which leads us to a call to default_debug_base.
>>
>> The way I propose to fix it is to add a call to
>> svr4_solib_ops::default_debug_base at the beginning of
>> svr4_solib_ops::current_sos.  The rationale to put it there is that if the
>> core is requesting a fresh list of libraries, and then compare that list
>> with what it had previously, then we better make sure that the core's list
>> has received the debug base update, if one is needed.
>>
>> Change-Id: If09c5a7b3d956e18d4b9514466226267c85f12a6
>> ---
>>  gdb/solib-svr4.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
>> index 635e52a19877..58432b69a5d5 100644
>> --- a/gdb/solib-svr4.c
>> +++ b/gdb/solib-svr4.c
>> @@ -1512,6 +1512,15 @@ owning_intrusive_list<solib>
>>  svr4_solib_ops::current_sos () const
>>  {
>>    svr4_info *info = get_svr4_info (current_program_space);
>> +
>> +  /* Call this for the side-effect of updating the debug base in existing
>> +     solibs' lm_info_svr4, if needed.  It is possible for the core to have
>> +     an solib with a stale lm_info_svr4::debug_base.  In that case, we are
>> +     about to return the same solib, but with an updated debug_base.  If we
>> +     didn't do this call, then it would appear as two different libraries to
>> +     the core, and it would appear as a spurious unload / load.  */
>> +  this->default_debug_base (info);
>> +
>>    owning_intrusive_list<solib> sos = this->current_sos_1 (info);
>>    struct mem_range vsyscall_range;
>>  
> 
> LGTM.
> 
> Approved-by: Kevin Buettner <kevinb@redhat.com>
> 

Thanks, pushed.

Simon