Fix Solaris gcore / shared libraries interaction

Fix Solaris gcore / shared libraries interaction

[Joseph S. Myers]

With some versions of the Solaris 10 dynamic linker, if you create a
core file with GDB's gcore command and then load that core file into
GDB, you get warnings of the form

warning: Can't read pathname for load map: I/O error.

on loading the core file.

The problem is that the l_name pointer for the dynamic linker, in the
process's link map, points into the read-only text segment of ld.so
(specifically, it points to the SONAME in the string table), and GDB
excludes this text segment when creating the core dump.  Normally
excluding text segments of shared libraries is fine, but in this case
it causes the above problems reloading the core dump.

This patch fixes the problem by arranging for read-only memory not to
be excluded from core dumps if it contains the l_name value.  OK to
commit?

2009-11-21  Joseph Myers  <joseph@codesourcery.com>

	* gcore.c: Include solib.h.
	(gcore_create_callback): Call solib_keep_data_in_core when
	considering not saving memory in core file.
	* solib-svr4.c (svr4_keep_data_in_core): New.
	(_initialize_svr4_solib): Initialize
	svr4_so_ops.keep_data_in_core.
	* solib.c (solib_keep_data_in_core): New.
	* solib.h (solib_keep_data_in_core): Declare.
	* solist.h (struct target_so_ops): Add keep_data_in_core.

Index: gdb/gcore.c
===================================================================
RCS file: /cvs/src/src/gdb/gcore.c,v
retrieving revision 1.35
diff -u -p -r1.35 gcore.c
--- gdb/gcore.c	22 Oct 2009 19:36:06 -0000	1.35
+++ gdb/gcore.c	20 Nov 2009 22:14:47 -0000
@@ -24,6 +24,7 @@
 #include "inferior.h"
 #include "gdbcore.h"
 #include "objfiles.h"
+#include "solib.h"
 #include "symfile.h"
 #include "arch-utils.h"
 #include "completer.h"
@@ -389,7 +390,7 @@ gcore_create_callback (CORE_ADDR vaddr, 
       return 0;
     }
 
-  if (write == 0)
+  if (write == 0 && !solib_keep_data_in_core (vaddr, size))
     {
       /* See if this region of memory lies inside a known file on disk.
 	 If so, we can avoid copying its contents by clearing SEC_LOAD.  */
Index: gdb/solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.107
diff -u -p -r1.107 solib-svr4.c
--- gdb/solib-svr4.c	10 Nov 2009 21:36:48 -0000	1.107
+++ gdb/solib-svr4.c	20 Nov 2009 22:14:47 -0000
@@ -866,6 +866,50 @@ solib_svr4_r_ldsomap (struct svr4_info *
 				    ptr_type);
 }
 
+/* On Solaris systems with some versions of the dynamic linker,
+   ld.so's l_name pointer points to the SONAME in the string table
+   rather than into writable memory.  So that GDB can find shared
+   libraries when loading a core file generated by gcore, ensure that
+   memory areas containing the l_name string are saved in the core
+   file.  */
+
+static int
+svr4_keep_data_in_core (CORE_ADDR vaddr, unsigned long size)
+{
+  struct svr4_info *info;
+  CORE_ADDR ldsomap;
+  struct so_list *new;
+  struct cleanup *old_chain;
+  struct link_map_offsets *lmo;
+  CORE_ADDR lm_name;
+
+  info = get_svr4_info ();
+
+  info->debug_base = 0;
+  locate_base (info);
+  if (!info->debug_base)
+    return 0;
+
+  ldsomap = solib_svr4_r_ldsomap (info);
+  if (!ldsomap)
+    return 0;
+
+  lmo = svr4_fetch_link_map_offsets ();
+  new = XZALLOC (struct so_list);
+  old_chain = make_cleanup (xfree, new);
+  new->lm_info = xmalloc (sizeof (struct lm_info));
+  make_cleanup (xfree, new->lm_info);
+  new->lm_info->l_addr = (CORE_ADDR)-1;
+  new->lm_info->lm_addr = ldsomap;
+  new->lm_info->lm = xzalloc (lmo->link_map_size);
+  make_cleanup (xfree, new->lm_info->lm);
+  read_memory (ldsomap, new->lm_info->lm, lmo->link_map_size);
+  lm_name = LM_NAME (new);
+  do_cleanups (old_chain);
+
+  return (lm_name >= vaddr && lm_name < vaddr + size);
+}
+
 /*
 
   LOCAL FUNCTION
@@ -1918,4 +1962,5 @@ _initialize_svr4_solib (void)
   svr4_so_ops.bfd_open = solib_bfd_open;
   svr4_so_ops.lookup_lib_global_symbol = elf_lookup_lib_symbol;
   svr4_so_ops.same = svr4_same;
+  svr4_so_ops.keep_data_in_core = svr4_keep_data_in_core;
 }
Index: gdb/solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.128
diff -u -p -r1.128 solib.c
--- gdb/solib.c	19 Oct 2009 09:51:42 -0000	1.128
+++ gdb/solib.c	20 Nov 2009 22:14:47 -0000
@@ -948,6 +948,23 @@ solib_name_from_address (struct program_
   return (0);
 }
 
+/* Return whether the data starting at VADDR, size SIZE, must be kept
+   in a core file for shared libraries loaded before "gcore" is used
+   to be handled correctly when the core file is loaded.  This only
+   applies when the section would otherwise not be kept in the core
+   file (in particular, for readonly sections).  */
+
+int
+solib_keep_data_in_core (CORE_ADDR vaddr, unsigned long size)
+{
+  struct target_so_ops *ops = solib_ops (target_gdbarch);
+
+  if (ops->keep_data_in_core)
+    return ops->keep_data_in_core (vaddr, size);
+  else
+    return 0;
+}
+
 /* Called by free_all_symtabs */
 
 void
Index: gdb/solib.h
===================================================================
RCS file: /cvs/src/src/gdb/solib.h,v
retrieving revision 1.25
diff -u -p -r1.25 solib.h
--- gdb/solib.h	19 Oct 2009 09:51:42 -0000	1.25
+++ gdb/solib.h	20 Nov 2009 22:14:47 -0000
@@ -52,6 +52,14 @@ extern char *solib_name_from_address (st
 
 extern int solib_contains_address_p (const struct so_list *, CORE_ADDR);
 
+/* Return whether the data starting at VADDR, size SIZE, must be kept
+   in a core file for shared libraries loaded before "gcore" is used
+   to be handled correctly when the core file is loaded.  This only
+   applies when the section would otherwise not be kept in the core
+   file (in particular, for readonly sections).  */
+
+extern int solib_keep_data_in_core (CORE_ADDR vaddr, unsigned long size);
+
 /* Return 1 if PC lies in the dynamic symbol resolution code of the
    run time loader.  */
 
Index: gdb/solist.h
===================================================================
RCS file: /cvs/src/src/gdb/solist.h,v
retrieving revision 1.26
diff -u -p -r1.26 solist.h
--- gdb/solist.h	19 Oct 2009 09:51:42 -0000	1.26
+++ gdb/solist.h	20 Nov 2009 22:14:47 -0000
@@ -126,6 +126,14 @@ struct target_so_ops
        Falls back to using strcmp on so_original_name field when set
        to NULL.  */
     int (*same) (struct so_list *gdb, struct so_list *inferior);
+
+    /* Return whether a region of memory must be kept in a core file
+       for shared libraries loaded before "gcore" is used to be
+       handled correctly when the core file is loaded.  This only
+       applies when the section would otherwise not be kept in the
+       core file (in particular, for readonly sections).  */
+    int (*keep_data_in_core) (CORE_ADDR vaddr,
+			      unsigned long size);
   };
 
 /* Free the memory associated with a (so_list *).  */

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Fix Solaris gcore / shared libraries interaction

[Jan Kratochvil]

Hi Joseph,


On Sat, 21 Nov 2009 01:10:27 +0100, Joseph S. Myers wrote:
> With some versions of the Solaris 10 dynamic linker, if you create a
> core file with GDB's gcore command and then load that core file into
> GDB, you get warnings of the form
> 
> warning: Can't read pathname for load map: I/O error.

The exactly the same problem+reasons affects not only GNU/Linux gcore but also
native kernel core dumps:

* glibc insists its behavior is correct
  http://sourceware.org/ml/libc-alpha/2009-10/msg00001.html

* core dumping in Linux kernel could be fixed but a patch containing similar
  deep understanding of link_map was already rejected before so I doubt this
  one would get accepted.

Isn't suitable the GDB change for the core file loading never replied here?
	[patch] Fix GNU/Linux core open: Can't read pathname for load map: Input/output error.
	http://sourceware.org/ml/gdb-patches/2009-10/msg00142.html


Thanks,
Jan

Re: Fix Solaris gcore / shared libraries interaction

[Joseph S. Myers]

On Sun, 22 Nov 2009, Jan Kratochvil wrote:

> * core dumping in Linux kernel could be fixed but a patch containing similar
>   deep understanding of link_map was already rejected before so I doubt this
>   one would get accepted.
> 
> Isn't suitable the GDB change for the core file loading never replied here?
> 	[patch] Fix GNU/Linux core open: Can't read pathname for load map: Input/output error.
> 	http://sourceware.org/ml/gdb-patches/2009-10/msg00142.html

On older GDB sources, I observed more warnings than those I quoted:

warning: Can't read pathname for load map: I/O error.
Reading symbols from /lib/64/libc.so.1...done.
Loaded symbols for /lib/64/libc.so.1

warning: Can't read pathname for load map: I/O error.

warning: Unable to find dynamic linker.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.

and "info shared" repeated the warning and did not show the dynamic 
linker, which suggested that things needed to be fixed so it could find 
this path, rather than just suppressing a warning.

For some reason, current FSF GDB sources do not produce all these extra 
warnings.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Fix Solaris gcore / shared libraries interaction

[Daniel Jacobowitz]

On Sun, Nov 22, 2009 at 03:34:21PM +0100, Jan Kratochvil wrote:
> Isn't suitable the GDB change for the core file loading never replied here?
> 	[patch] Fix GNU/Linux core open: Can't read pathname for load map: Input/output error.
> 	http://sourceware.org/ml/gdb-patches/2009-10/msg00142.html

No.  In that patch, the name of one DSO (the vDSO) is in another DSO
(ld.so).  In the Solaris case, the name of ld.so is in its own
read-only segment.  So if you don't dump that page into the core file,
no matter how you iterate you will never find the path to ld.so.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Fix Solaris gcore / shared libraries interaction

[Jan Kratochvil]

On Sun, 22 Nov 2009 16:18:15 +0100, Daniel Jacobowitz wrote:
> On Sun, Nov 22, 2009 at 03:34:21PM +0100, Jan Kratochvil wrote:
> > Isn't suitable the GDB change for the core file loading never replied here?
> > 	[patch] Fix GNU/Linux core open: Can't read pathname for load map: Input/output error.
> > 	http://sourceware.org/ml/gdb-patches/2009-10/msg00142.html
> 
> No.  In that patch, the name of one DSO (the vDSO) is in another DSO
> (ld.so).  In the Solaris case, the name of ld.so is in its own
> read-only segment.  So if you don't dump that page into the core file,
> no matter how you iterate you will never find the path to ld.so.

OK, I cannot say more as it is not reproducible for me on OpenSolaris 2009.06
snv_111b X86 so it may affect only older Solaris versions:

On Sat, 21 Nov 2009 01:10:27 +0100, Joseph S. Myers wrote:
# With some versions of the Solaris 10 dynamic linker,

Seeing on OpenSolaris 2009.06 snv_111b X86 no GDB warnings and:

(gdb) info sharedlibrary
LM_NAME=0xfefa009f
LM_NAME=0xfefa0000
From        To          Syms Read   Shared Object Library
0xfee6e0d0  0xfef25c00  Yes (*)     /lib/libc.so.1
0xfefc52a0  0xfefe61fb  Yes (*)     /lib/ld.so.1
core:
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x155f10 0xfefa0000 0x00000000 0x01000 0x01000 RW  0
gcore:
  LOAD           0x15471c 0xfefa0000 0x00000000 0x01000 0x01000 RW  0x1

(gdb) info sharedlibrary
LM_NAME=0xfffffd7fff380094
LM_NAME=0xfffffd7fff380000
From                To                  Syms Read   Shared Object Library
0xfffffd7fff220940  0xfffffd7fff2eaf88  Yes (*)     /lib/64/libc.so.1
0xfffffd7fff3bb3d0  0xfffffd7fff3e5a2e  Yes (*)     /lib/amd64/ld.so.1
core64:
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x1afa0c 0xfffffd7fff380000 0x0000000000000000 0x001000 0x001000 RW  0
gcore64:
  LOAD           0x017bf0 0xfffffd7fff380000 0x0000000000000000 0x001000 0x001000 RW  0x1


Regards,
Jan

Re: Fix Solaris gcore / shared libraries interaction

[Joseph S. Myers]

On Sun, 22 Nov 2009, Jan Kratochvil wrote:

> OK, I cannot say more as it is not reproducible for me on OpenSolaris 2009.06
> snv_111b X86 so it may affect only older Solaris versions:
> 
> On Sat, 21 Nov 2009 01:10:27 +0100, Joseph S. Myers wrote:
> # With some versions of the Solaris 10 dynamic linker,

The "some versions" was intended to mean with newer versions but not older 
ones - I could observe it on a Solaris x86 system with a dynamic linker 
from 2007, but not a SPARC system with one from 2005, and it appears a 
relevant change (no longer calling strdup on the name) went in the second 
revision of cmd/sgs/rtld/common/setup.c in the public OpenSolaris version 
history.  But it's possible further OpenSolaris changes have affected 
things again there.

-- 
Joseph S. Myers
joseph@codesourcery.com

Ping Re: Fix Solaris gcore / shared libraries interaction

[Joseph S. Myers]

Ping.  This patch 
<http://sourceware.org/ml/gdb-patches/2009-11/msg00454.html> is pending 
review.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Ping Re: Fix Solaris gcore / shared libraries interaction

[Daniel Jacobowitz]

On Sat, Nov 28, 2009 at 08:11:51PM +0000, Joseph S. Myers wrote:
> Ping.  This patch 
> <http://sourceware.org/ml/gdb-patches/2009-11/msg00454.html> is pending 
> review.

This patch is OK.

-- 
Daniel Jacobowitz
CodeSourcery