[KLUDGE PATCH] Linux vsyscall DSO support

[KLUDGE PATCH] Linux vsyscall DSO support

[Roland McGrath]

Perhaps you recall the discussion here some months back about what hook to
use in Linux targets for the detection of the vsyscall DSO.  The last time
I asked here about a resolution on how best to do this, I got no feedback.
I hope we can now jumpstart the effort to find the right way to implement
this.  To get things rolling again, here is a patch that I am not
suggesting for inclusion, but does work.  This is a kludge to overload the
solib hooks with target-specific code.  These solib hooks get called at
roughly (or perhaps even precisely?) the correct places where the vsyscall
DSO checks ought to happen.  A reminder, the appropriate places are when
gdb thinks the address space might be a fresh layout from what it knows,
i.e. first attach (or any attach?), after exec, and on opening a core file.

As I said, this code works for me.  (It requires symbol_file_add_from_memory,
which is in the patch I just re-posted.)  It seems doubtful this is the
ultimately desireable approach to wedging this code in where needs to be.
But it's what I've got, and as I said I'm still waiting for more feedback to
conclude on exactly what the preferred better thing to do is.


Thanks,
Roland


2003-10-09  Roland McGrath  <roland@redhat.com>

	* solib.c (do_clear_solib): Use CLEAR_SOLIB macro instead of
	clear_solib function, so that a target macro can override the defn.
	* linux-tdep.c: New file.
	* Makefile.in (linux-tdep.o): New target.
	(ALLDEPFILES): Add it.
	* config/i386/linux.mt (TDEPFILES): Likewise.
	* config/ia64/linux.mt (TDEPFILES): Likewise.
	* config/s390/s390x.mt (TDEPFILES): Likewise.
	* config/sh/linux.mt (TDEPFILES): Likewise.
	* config/mips/linux.mt (TDEPFILES): Likewise.
	* config/s390/s390.mt (TDEPFILES): Likewise.
	* config/arm/linux.mt (TDEPFILES): Likewise.
	* config/m68k/linux.mt (TDEPFILES): Likewise.
	* config/sparc/linux.mt (TDEPFILES): Likewise.
	* config/powerpc/linux.mt (TDEPFILES): Likewise.

Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.64
diff -b -p -u -r1.64 solib.c
--- solib.c	11 Mar 2004 17:04:40 -0000	1.64
+++ solib.c	8 Apr 2004 20:50:50 -0000
@@ -778,7 +778,7 @@ static void
 do_clear_solib (void *dummy)
 {
   solib_cleanup_queued = 0;
-  clear_solib ();
+  CLEAR_SOLIB ();		/* Let tm.h override.  */
 }
 
 /* GLOBAL FUNCTION
Index: linux-tdep.c
===================================================================
RCS file: linux-tdep.c
diff -N linux-tdep.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ linux-tdep.c	8 Apr 2004 20:50:50 -0000
@@ -0,0 +1,39 @@
+#include "defs.h"
+#include "solib.h"
+#include "symtab.h"
+#include "symfile.h"
+#include "objfiles.h"
+#include "target.h"
+
+#include <elf/common.h>
+#include "auxv.h"
+
+static int checked_inferior_sysinfo;
+
+void
+linux_solib_add (char *pattern, int from_tty,
+		 struct target_ops *target, int readsyms)
+{
+  if (!checked_inferior_sysinfo)
+    {
+      extern bfd *core_bfd, *exec_bfd;
+      CORE_ADDR sysinfo_ehdr;
+
+      if (target_auxv_search (target, AT_SYSINFO_EHDR, &sysinfo_ehdr) > 0
+	  && sysinfo_ehdr != (CORE_ADDR) 0)
+	(void) symbol_file_add_from_memory
+	  (core_bfd != NULL ? core_bfd : exec_bfd, sysinfo_ehdr, from_tty);
+
+      checked_inferior_sysinfo = 1;
+    }
+
+  solib_add (pattern, from_tty, target, readsyms);
+}
+
+void
+linux_clear_solib (void)
+{
+  clear_solib ();
+
+  checked_inferior_sysinfo = 0;
+}
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.534
diff -b -p -u -r1.534 Makefile.in
--- Makefile.in	7 Apr 2004 00:04:28 -0000	1.534
+++ Makefile.in	8 Apr 2004 20:50:52 -0000
@@ -1330,6 +1330,7 @@ ALLDEPFILES = \
 	i386gnu-nat.c i386gnu-tdep.c \
 	ia64-linux-nat.c ia64-linux-tdep.c ia64-tdep.c \
 	infptrace.c inftarg.c irix4-nat.c irix5-nat.c \
+	linux-tdep.c \
 	libunwind-frame.c \
 	lynx-nat.c m3-nat.c \
 	m68hc11-tdep.c \
@@ -1972,6 +1973,8 @@ linux-nat.o: linux-nat.c $(defs_h) $(inf
 linux-proc.o: linux-proc.c $(defs_h) $(inferior_h) $(gdb_stat_h) \
 	$(regcache_h) $(gregset_h) $(gdbcore_h) $(gdbthread_h) $(elf_bfd_h) \
 	$(cli_decode_h) $(gdb_string_h) $(linux_nat_h)
+linux-tdep.o: linux-tdep.c $(defs_h) $(solib_h) $(symtab_h) $(symfile_h) \
+	$(objfiles_h) $(target_h)  $(elf_external_h) $(elf_common_h)
 lynx-nat.o: lynx-nat.c $(defs_h) $(frame_h) $(inferior_h) $(target_h) \
 	$(gdbcore_h) $(regcache_h)
 m2-exp.o: m2-exp.c $(defs_h) $(gdb_string_h) $(expression_h) $(language_h) \
Index: config/arm/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/arm/linux.mt,v
retrieving revision 1.7
diff -b -p -u -r1.7 linux.mt
--- config/arm/linux.mt	9 Nov 2003 17:28:07 -0000	1.7
+++ config/arm/linux.mt	8 Apr 2004 20:50:52 -0000
@@ -1,3 +1,3 @@
 # Target: ARM based machine running GNU/Linux
 TM_FILE= tm-linux.h
-TDEPFILES= arm-tdep.o arm-linux-tdep.o glibc-tdep.o solib.o solib-svr4.o solib-legacy.o
+TDEPFILES= linux-tdep.o arm-tdep.o arm-linux-tdep.o glibc-tdep.o solib.o solib-svr4.o solib-legacy.o
Index: config/i386/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/linux.mt,v
retrieving revision 1.7
diff -b -p -u -r1.7 linux.mt
--- config/i386/linux.mt	9 Nov 2003 17:28:08 -0000	1.7
+++ config/i386/linux.mt	8 Apr 2004 20:50:52 -0000
@@ -1,4 +1,5 @@
 # Target: Intel 386 running GNU/Linux
-TDEPFILES= i386-tdep.o i386-linux-tdep.o glibc-tdep.o i387-tdep.o \
+TDEPFILES= linux-tdep.o \
+	   i386-tdep.o i386-linux-tdep.o glibc-tdep.o i387-tdep.o \
 	solib.o solib-svr4.o solib-legacy.o
 TM_FILE= tm-linux.h
Index: config/ia64/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/ia64/linux.mt,v
retrieving revision 1.8
diff -b -p -u -r1.8 linux.mt
--- config/ia64/linux.mt	20 Jun 2003 13:57:29 -0000	1.8
+++ config/ia64/linux.mt	8 Apr 2004 20:50:52 -0000
@@ -1,4 +1,4 @@
 # Target: Intel IA-64 running GNU/Linux
-TDEPFILES= ia64-tdep.o ia64-aix-tdep.o ia64-linux-tdep.o \
+TDEPFILES= linux-tdep.o ia64-tdep.o ia64-aix-tdep.o ia64-linux-tdep.o \
 	solib.o solib-svr4.o solib-legacy.o
 TM_FILE= tm-linux.h
Index: config/m68k/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/m68k/linux.mt,v
retrieving revision 1.4
diff -b -p -u -r1.4 linux.mt
--- config/m68k/linux.mt	19 Nov 2002 23:14:45 -0000	1.4
+++ config/m68k/linux.mt	8 Apr 2004 20:50:52 -0000
@@ -1,3 +1,4 @@
 # Target: Motorola m68k with a.out and ELF
-TDEPFILES= m68k-tdep.o m68klinux-tdep.o solib.o solib-svr4.o solib-legacy.o
+TDEPFILES= linux-tdep.o m68k-tdep.o m68klinux-tdep.o \
+	   solib.o solib-svr4.o solib-legacy.o
 TM_FILE= tm-linux.h
Index: config/mips/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/mips/linux.mt,v
retrieving revision 1.3
diff -b -p -u -r1.3 linux.mt
--- config/mips/linux.mt	20 Jun 2003 13:57:29 -0000	1.3
+++ config/mips/linux.mt	8 Apr 2004 20:50:52 -0000
@@ -1,5 +1,5 @@
 # Target: Linux/MIPS
-TDEPFILES= mips-tdep.o mips-linux-tdep.o corelow.o \
+TDEPFILES= linux-tdep.o mips-tdep.o mips-linux-tdep.o corelow.o \
 	solib.o solib-svr4.o
 TM_FILE= tm-linux.h
 
Index: config/powerpc/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/linux.mt,v
retrieving revision 1.6
diff -b -p -u -r1.6 linux.mt
--- config/powerpc/linux.mt	30 Jul 2002 19:03:49 -0000	1.6
+++ config/powerpc/linux.mt	8 Apr 2004 20:50:52 -0000
@@ -1,6 +1,6 @@
 # Target: Motorola PPC on Linux
-TDEPFILES= rs6000-tdep.o ppc-linux-tdep.o ppc-sysv-tdep.o solib.o \
-	solib-svr4.o solib-legacy.o corelow.o
+TDEPFILES= linux-tdep.o rs6000-tdep.o ppc-linux-tdep.o ppc-sysv-tdep.o \
+	   solib.o solib-svr4.o solib-legacy.o corelow.o
 TM_FILE= tm-linux.h
 
 SIM_OBS = remote-sim.o
Index: config/sh/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/sh/linux.mt,v
retrieving revision 1.6
diff -b -p -u -r1.6 linux.mt
--- config/sh/linux.mt	10 Oct 2003 07:13:11 -0000	1.6
+++ config/sh/linux.mt	8 Apr 2004 20:50:52 -0000
@@ -1,5 +1,7 @@
 # Target: Renesas Super-H running GNU/Linux
-TDEPFILES= sh-tdep.o sh64-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o solib-legacy.o
+TDEPFILES= linux-tdep.o sh-tdep.o sh64-tdep.o \
+	   monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o \
+	   solib.o solib-svr4.o solib-legacy.o
 TM_FILE= tm-linux.h
 
 SIM_OBS = remote-sim.o
Index: config/sparc/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/sparc/linux.mt,v
retrieving revision 1.5
diff -b -p -u -r1.5 linux.mt
--- config/sparc/linux.mt	7 Apr 2004 00:15:12 -0000	1.5
+++ config/sparc/linux.mt	8 Apr 2004 20:50:52 -0000
@@ -1,4 +1,4 @@
 # Target: GNU/Linux SPARC
 TDEPFILES= sparc-tdep.o sparc-sol2-tdep.o sparc-linux-tdep.o \
-	solib.o solib-svr4.o
+	solib.o solib-svr4.o linux-tdep.o
 TM_FILE= tm-linux.h

Re: [KLUDGE PATCH] Linux vsyscall DSO support

[Andrew Cagney]

Roland, FYI.

Last time this was discussed the observer was identified as the correct 
mechanim for hooking this in.  That's why I'm currently overhauling that 
code.

Andrew

> Perhaps you recall the discussion here some months back about what hook to
> use in Linux targets for the detection of the vsyscall DSO.  The last time
> I asked here about a resolution on how best to do this, I got no feedback.
> I hope we can now jumpstart the effort to find the right way to implement
> this.  To get things rolling again, here is a patch that I am not
> suggesting for inclusion, but does work.  This is a kludge to overload the
> solib hooks with target-specific code.  These solib hooks get called at
> roughly (or perhaps even precisely?) the correct places where the vsyscall
> DSO checks ought to happen.  A reminder, the appropriate places are when
> gdb thinks the address space might be a fresh layout from what it knows,
> i.e. first attach (or any attach?), after exec, and on opening a core file.
> 
> As I said, this code works for me.  (It requires symbol_file_add_from_memory,
> which is in the patch I just re-posted.)  It seems doubtful this is the
> ultimately desireable approach to wedging this code in where needs to be.
> But it's what I've got, and as I said I'm still waiting for more feedback to
> conclude on exactly what the preferred better thing to do is.
> 
> 

Re: [KLUDGE PATCH] Linux vsyscall DSO support

[Roland McGrath]

> Last time this was discussed the observer was identified as the correct 
> mechanim for hooking this in.  That's why I'm currently overhauling that 
> code.

Ok.  I forget many things, but I think this is news to me.  I hadn't seen
the "observer" code before; I now see it's a simple facility for running a
list multiple hooks previously registered, so this is today's preferred
form of adding a new hook.  Two questions remain for me:

What is the new hook or hooks you plan to add?  i.e., will it be a single
"look freshly at address space" hook, or separate hooks for "attached",
"exec'd", "opened core", etc?  It matters little, unless we anticipate
future different situations that would also qualify as "look freshly at
address space" situations but aren't one of the three I listed.

Where is the right place to install our observer?  My inclination is to add
linux-tdep.c to all the Linux targets as my strawman patch does, and have
an _initialize_linux_tdep function that registers the observers.  Is that
what you are thinking as well?


Thanks,
Roland

Re: [KLUDGE PATCH] Linux vsyscall DSO support

[Andrew Cagney]

>>> Last time this was discussed the observer was identified as the correct 
>>> mechanim for hooking this in.  That's why I'm currently overhauling that 
>>> code.
> 
> 
> Ok.  I forget many things, but I think this is news to me.

I remember sending an explicit e-mail, I suspect you didn't see it as 
your mailing address got trimmed part way through the thread :-(

>  I hadn't seen
> the "observer" code before; I now see it's a simple facility for running a
> list multiple hooks previously registered, so this is today's preferred
> form of adding a new hook.  Two questions remain for me:
> 
> What is the new hook or hooks you plan to add?  i.e., will it be a single
> "look freshly at address space" hook, or separate hooks for "attached",
> "exec'd", "opened core", etc?  It matters little, unless we anticipate
> future different situations that would also qualify as "look freshly at
> address space" situations but aren't one of the three I listed.

I think there should be a something like a "new_inferior" event that 
incorporates "run", "attach", and "corefile".  As we've recently 
discovered, "run" is just a slight simplification of attach.  (Because 
of some screwieness in how the target vector is [isn't] designed, a 
number of files will need to have the call added - that can be handled 
as identified).

> Where is the right place to install our observer?  My inclination is to add
> linux-tdep.c to all the Linux targets as my strawman patch does, and have
> an _initialize_linux_tdep function that registers the observers.  Is that
> what you are thinking as well?

Guess so.  The decsion to load one of these shlibs is really based 
solely on the presence of that AT_xxxx auxv entry and the observer gets 
to check that.

Andrew