gdb/solib-svr4: update default debug base in svr4_solib_ops::current_sos

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
Approved-by: Kevin Buettner <kevinb@redhat.com>

0 files changed, 0 insertions, 0 deletions