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

[Simon Marchi <simark@simark.ca>]

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