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: [patch] solib-svr4.c - allow reading linkmap info from core without executable


Is this ok to commit?

Aleksandar Ristovski wrote:
Pedro Alves wrote:
   if (info->debug_base == 0 && svr4_have_link_map_offsets ())
     {
-      if (exec_bfd != NULL
+      if ((exec_bfd != NULL
          && bfd_get_flavour (exec_bfd) == bfd_target_elf_flavour)
+         || (core_bfd != NULL
+             && bfd_get_flavour (core_bfd) == bfd_target_elf_flavour))
        info->debug_base = elf_locate_base ();
     }

Are there live debugging cases (archs?, PIE?) (e.g., "target remote" without specifying an executable) where letting elf_locate_base
try to read the debug base from the target's auxv (scan_dyntag_auxv)
will work? It would mean that removing the exec_bfd checks instead
of adding core_bfd checks, would still improve your case, while
letting other cases benefit as well.



Yes, in theory it should work as long as target_ops in question know how to read auxv (that is, as long as to_xfer_partial(ops, TARGET_OBJECT_AUXV,...) knows how to do it.)


I had internally made this change:

    {
-     if (exec_bfd != NULL
+      if ((exec_bfd != NULL
          && bfd_get_flavour (exec_bfd) == bfd_target_elf_flavour)
+          || exec_bfd == NULL)
        debug_base = elf_locate_base ();
    }
  return (debug_base);


But wanted to be more conservative for FSF, since I do not quite understand under which circumstances could we end up in solib-svr4, and not have "bfd_target_elf_flavour".



Thanks,




--
Aleksandar Ristovski
QNX Software Systems


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