Re: [PING] [PATCH] Rebase executable to match relocated base address

["Hannes Domani via gdb-patches" <gdb-patches at sourceware dot org>]

 Am Dienstag, 11. Februar 2020, 01:29:44 MEZ hat Luis Machado <luis.machado@linaro.org> Folgendes geschrieben:

> On 2/8/20 1:37 PM, Hannes Domani via gdb-patches wrote:
> > Ping.
> >
> > Am Samstag, 25. Januar 2020, 17:47:19 MEZ hat Hannes Domani via gdb-patches <gdb-patches@sourceware.org> Folgendes geschrieben:
> >
> >> Compared to the [RFC], only Tom's noticed coding style problems were
> >> fixed.
> >>
> >> binutils 2.34 will have an improved -dynamicbase (so far this only
> >> worked with some workarounds for executables), so the rebasing problem
> >> might get more relevant in the future.
> >>
> >>
> >> Windows executables linked with -dynamicbase get a new base address
> >> when loaded, which makes debugging impossible if the executable isn't
> >> also rebased in gdb.
> >>
> >> The transfer of the new base address is done via a fake auxv entry,
> >> so it's working with gdbserver as well.
> >>
> >> gdb/ChangeLog:
> >>
> >> 2020-01-25  Hannes Domani  <ssbssa@yahoo.de>
> >>
> >>       * windows-nat.c (windows_nat_target::get_windows_debug_event):
> >>       Set current_exec_base.
> >>       (windows_xfer_auxv): New function.
> >>       (windows_nat_target::xfer_partial): Call windows_xfer_auxv.
> >>       * windows-tdep.c (windows_solib_create_inferior_hook): New function.
> >>       (windows_init_abi): Use windows_solib_create_inferior_hook.
> >>
> >> gdb/gdbserver/ChangeLog:
> >>
> >> 2020-01-25  Hannes Domani  <ssbssa@yahoo.de>
> >>
> >>       * win32-low.c (get_child_debug_event): Set current_exec_base.
> >>       (win32_read_auxv): New function.
> >> ---
> >> gdb/gdbserver/win32-low.c | 35 ++++++++++++++++++++++++++++++++++-
> >> gdb/windows-nat.c        | 38 ++++++++++++++++++++++++++++++++++++++
> >> gdb/windows-tdep.c        | 20 ++++++++++++++++++++
> >> 3 files changed, 92 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/gdb/gdbserver/win32-low.c b/gdb/gdbserver/win32-low.c
> >> index 2c4a9b1074..2f6fe5785e 100644
> >> --- a/gdb/gdbserver/win32-low.c
> >> +++ b/gdb/gdbserver/win32-low.c
> >> @@ -75,6 +75,7 @@ static int attaching = 0;
> >> static HANDLE current_process_handle = NULL;
> >> static DWORD current_process_id = 0;
> >> static DWORD main_thread_id = 0;
> >> +static CORE_ADDR current_exec_base;    /* Executable base address */
>
> Set current_exec_base to 0 so it gets explicitly initialized?

OK.


> >> static enum gdb_signal last_sig = GDB_SIGNAL_0;
> >>
> >> /* The current debug event from WaitForDebugEvent.  */
> >> @@ -1486,6 +1487,8 @@ get_child_debug_event (struct target_waitstatus *ourstatus)
> >>
> >>         current_process_handle = current_event.u.CreateProcessInfo.hProcess;
> >>         main_thread_id = current_event.dwThreadId;
> >> +      current_exec_base
> >> +    = (CORE_ADDR) current_event.u.CreateProcessInfo.lpBaseOfImage;
>
> Formatting of the second line looks funny. Should be moved forward.

OK.


> Has the lpBaseOfImage member variable always been there and was never
> used? From what i looked at MSDN, it looks like it.

Yes.


> >>
> >>         /* Add the main thread.  */
> >>         child_add_thread (current_event.dwProcessId,
> >> @@ -1713,6 +1716,36 @@ win32_request_interrupt (void)
> >>     soft_interrupt_requested = 1;
> >> }
> >>
> >> +/* Windows does not have auxv, but this creates a fake AT_ENTRY entry
> >> +  which is the base address of the executable.  */
> >> +
> >> +static int
> >> +win32_read_auxv (CORE_ADDR offset, unsigned char *myaddr, unsigned int len)
> >> +{
> >> +  size_t buf[4];
> >> +
> >> +  if (!myaddr)
> >> +    return -1;
> >> +
> >> +  if (offset > sizeof (buf))
> >> +    return -1;
> >> +
> >> +  if (offset == sizeof (buf))
> >> +    return 0;
> >> +
> >> +  if (offset + len > sizeof (buf))
> >> +    len = sizeof (buf) - offset;
> >> +
> >> +  buf[0] = 9; /* AT_ENTRY */
> >> +  buf[1] = current_exec_base;
> >> +  buf[2] = 0; /* AT_NULL */
> >> +  buf[3] = 0;
> >> +
> >> +  memcpy (myaddr, (char *) buf + offset, len);
> >> +
> >> +  return len;
> >> +}
> >> +
> >> #ifdef _WIN32_WCE
> >> int
> >> win32_error_to_fileio_error (DWORD err)
> >> @@ -1814,7 +1847,7 @@ static process_stratum_target win32_target_ops = {
> >>     win32_write_inferior_memory,
> >>     NULL, /* lookup_symbols */
> >>     win32_request_interrupt,
> >> -  NULL, /* read_auxv */
> >> +  win32_read_auxv,
> >>     win32_supports_z_point_type,
> >>     win32_insert_point,
> >>     win32_remove_point,
> >> diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
> >> index 366c98fbf3..459bb10fe9 100644
> >> --- a/gdb/windows-nat.c
> >> +++ b/gdb/windows-nat.c
> >> @@ -236,6 +236,7 @@ static DEBUG_EVENT current_event;    /* The current debug event from
> >>                         WaitForDebugEvent */
> >> static HANDLE current_process_handle;    /* Currently executing process */
> >> static windows_thread_info *current_thread;    /* Info on currently selected thread */
> >> +static CORE_ADDR current_exec_base;    /* Executable base address */
> >>
> >> /* Counts of things.  */
> >> static int exception_count = 0;
> >> @@ -1604,6 +1605,8 @@ windows_nat_target::get_windows_debug_event (int pid,
> >>       break;
> >>
> >>         current_process_handle = current_event.u.CreateProcessInfo.hProcess;
> >> +      current_exec_base
> >> +    = (CORE_ADDR) current_event.u.CreateProcessInfo.lpBaseOfImage;
> >>         /* Add the main thread.  */
> >>         th = windows_add_thread
> >>           (ptid_t (current_event.dwProcessId, 0,
> >> @@ -2996,6 +2999,38 @@ windows_xfer_shared_libraries (struct target_ops *ops,
> >>     return len != 0 ? TARGET_XFER_OK : TARGET_XFER_EOF;
> >> }
> >>
> >> +/* Windows does not have auxv, but this creates a fake AT_ENTRY entry
> >> +  which is the base address of the executable.  */
> >> +
> >> +static enum target_xfer_status
> >> +windows_xfer_auxv (gdb_byte *readbuf, ULONGEST offset, ULONGEST len,
> >> +          ULONGEST *xfered_len)
> >> +{
> >> +  CORE_ADDR buf[4];
> >> +
> >> +  if (!readbuf)
> >> +    return TARGET_XFER_E_IO;
> >> +
> >> +  if (offset > sizeof (buf))
> >> +    return TARGET_XFER_E_IO;
> >> +
> >> +  if (offset == sizeof (buf))
> >> +    return TARGET_XFER_EOF;
> >> +
> >> +  if (offset + len > sizeof (buf))
> >> +    len = sizeof (buf) - offset;
> >> +
> >> +  buf[0] = 9; /* AT_ENTRY */
> >> +  buf[1] = current_exec_base;
> >> +  buf[2] = 0; /* AT_NULL */
> >> +  buf[3] = 0;
> >> +
> >> +  memcpy (readbuf, (char *) buf + offset, len);
> >> +  *xfered_len = len;
> >> +
> >> +  return TARGET_XFER_OK;
> >> +}
> >> +
> >> enum target_xfer_status
> >> windows_nat_target::xfer_partial (enum target_object object,
> >>                     const char *annex, gdb_byte *readbuf,
> >> @@ -3011,6 +3046,9 @@ windows_nat_target::xfer_partial (enum target_object object,
> >>         return windows_xfer_shared_libraries (this, object, annex, readbuf,
> >>                           writebuf, offset, len, xfered_len);
> >>
> >> +    case TARGET_OBJECT_AUXV:
> >> +      return windows_xfer_auxv (readbuf, offset, len, xfered_len);
> >> +
> >>       default:
> >>         if (beneath () == NULL)
> >>       {
> >> diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c
> >> index 6c9632d035..fd491e8e67 100644
> >> --- a/gdb/windows-tdep.c
> >> +++ b/gdb/windows-tdep.c
> >> @@ -34,6 +34,10 @@
> >> #include "solib.h"
> >> #include "solib-target.h"
> >> #include "gdbcore.h"
> >> +#include "coff/internal.h"
> >> +#include "libcoff.h"
> >> +#include "solist.h"
> >> +#include "auxv.h"
> >>
> >> /* Windows signal numbers differ between MinGW flavors and between
> >>       those and Cygwin.  The below enumeration was gleaned from the
> >> @@ -656,6 +660,20 @@ windows_gdb_signal_to_target (struct gdbarch *gdbarch, enum gdb_signal signal)
> >>     return -1;
> >> }
> >>
> >> +static void
> >> +windows_solib_create_inferior_hook (int from_tty)
>
>
> Missing documentation for this function.

Right.


> This function is needed, but the question is how it should get the base
> address from the target.
>
> The auxv trickery works, but that may have other implications. I'm not
> sure if GDB won't try to fetch more stuff given we now have an "auxv".
> And it is also a bit misleading.

I've used this approach for a while now, and never had any problem with it.
Also, gnu-nat.c creates a fake auxv entry as well.


> Is there some other way one can fetch this data? Registers? Memory?

I'm not sure how that would work.


> If not, then maybe we could create a new qxfer request to fetch this
> data for Windows, say, TARGET_OBJECT_WINDOWS_LOADBASE. It would be
> cleaner and would handle both gdbserver and gdb.
>
> In case we want to make the request more generic, maybe call it
> TARGET_OBJECT_EXEC_LOADBASE or somesuch.

I agree that this would be the cleanest solution, but I thought touching
the gdbserver interface isn't the best idea when it can be avoided.


Regards
Hannes Domani