This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA 2/5] Darwin: Handle unrelocated dyld.


On 2018-09-19 15:15, Tom Tromey wrote:
"Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:

Simon> I would vote for only checking in the code you know is necessary for Simon> now, otherwise it will just be more confusing in the future, trying to
Simon> figure out what is needed and what isn't.

Here is a more minimal version of the patch. This one seems to work for
me on High Sierra.  I tried running a "hello world" program -- this
previously failed, but now works.  It's good enough that I could run
gdb.cp/*.exp -- lots of fails but no crashes or mystery problems.

Tom

commit 114a1aae792443d72f1438dbc979b42a39c5b780
Author: Xavier Roirand <roirand@adacore.com>
Date:   Wed Aug 22 12:11:14 2018 +0200

    Darwin: Handle unrelocated dyld.

    On Darwin, debugging an helloworld program with GDB does
    not work and ends with:

      (gdb) set startup-with-shell off
      (gdb) start
Temporary breakpoint 1 at 0x100000fb4: file /tmp/helloworld.c, line 1.
      Starting program: /private/tmp/helloworld
      [New Thread 0x2703 of process 18906]
      [New Thread 0x2603 of process 18906]

      [1]+  Stopped                 ./gdb/gdb /tmp/helloworld

    When debugging with lldb, instead of having the STOP signal, we can
    see that a breakpoint is not set to a proper location:

      Warning:
      Cannot insert breakpoint -1.
      Cannot access memory at address 0xf726

      Command aborted.

The inserted breakpoint is the one used when GDB has to stop the target when a shared library is loaded or unloaded. The notifier address used
    for adding the breakpoint is wrong thus the above failure.
This notifier address is an offset relative to dyld base address, so
    the value calculation has to be updated to reflect this.

This was tested on High Sierra by trying to run a simple "hello world"
    program.

Works for me, thanks!  I just noted some nits.

@@ -459,6 +457,18 @@ darwin_solib_get_all_image_info_addr_at_init
(struct darwin_info *info)
       else
 	dyld_bfd.release ();
     }
+  return dyld_bfd;
+}
+
+/* Extract dyld_all_image_addr when the process was just created, assuming the
+   current PC is at the entry of the dynamic linker.  */
+
+static void
+darwin_solib_get_all_image_info_addr_at_init (struct darwin_info *info)
+{
+  CORE_ADDR load_addr = 0;
+  gdb_bfd_ref_ptr dyld_bfd (darwin_get_dyld_bfd ());

Use =.

+
   if (dyld_bfd == NULL)
     return;

@@ -528,10 +538,6 @@ darwin_solib_create_inferior_hook (int from_tty)
       return;
     }

-  /* Add the breakpoint which is hit by dyld when the list of solib is
-     modified.  */
- create_solib_event_breakpoint (target_gdbarch (), info->all_image.notifier);
-
   if (info->all_image.count != 0)
     {
       /* Possible relocate the main executable (PIE).  */
@@ -558,6 +564,49 @@ darwin_solib_create_inferior_hook (int from_tty)
       if (vmaddr != load_addr)
 	objfile_rebase (symfile_objfile, load_addr - vmaddr);
     }
+
+  /* Set solib notifier (to reload list of shared libraries).  */
+  CORE_ADDR notifier = info->all_image.notifier;
+
+  if (info->all_image.count == 0)
+    {
+      /* Dyld hasn't yet relocated itself, so the notifier address may
+	 be incorrect (as it has to be relocated).  */
+      CORE_ADDR start = bfd_get_start_address (exec_bfd);
+      if (start == 0)
+	notifier = 0;
+      else
+        {
+          gdb_bfd_ref_ptr dyld_bfd (darwin_get_dyld_bfd ());

Here too.

Simon


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]