unwind support for Linux 2.6 vsyscall DSO

unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

In the past (during this spring and summer) there were some discussions
about the need to find unwind info in the vsyscall DSO image implicitly
loaded in processes on Linux 2.5/2.6 on some platforms.  I honestly don't
recall which mailing lists this was on.  If people are not clear on the
issues, I can try to dig up the various summaries of the details I have
posted before.  This was tabled for a while when I had other priorities
since it didn't turn out to be an issue with any kernel version used by
Red Hat production systems.

Now Linux 2.6 is getting firmed up, and it's time to revisit this.  On
Linux 2.6 kernels, backtraces from programs stopped in system calls do not
work using current glibc on x86 and AMD64 machines.  The same issue exists
on IA64 in Linux 2.6, and glibc will before long make use of the feature so
that system call backtraces need the same solutions for IA64.

My changes to export the auxv information in core dumps and /proc are now
making their way into Linux 2.6, and this gives us the tools we need to
solve the problem in gdb.

The following patches are some kludges I have tried out.  They are not fit
for inclusion, but demonstrate what needs to be done.  I hope they can
stimulate some advice on where such code should actually go.

This patch relies on the symbol_file_add_from_memory function introduced by
the patch I just posted a little earlier.  Please review that patch first
as context for what I'm doing here.  With that patch plus this one, on a Linux
2.6 kernel with the very latest patches you surely don't have quite yet, a
backtrace starting in the vsyscall entry point is unwound correctly from a
core file and when using attach.

Basically what needs to happen is a few places that should implicitly call
symbol_file_add_from_memory on the address the kernel supplied with the
AT_SYSINFO_EHDR tag on process startup.  On examining a core file, the
NT_AUXV note contains this info, and BFD makes it available as a ".auxv"
fake section.  On running or attaching to a live process, the
/proc/PID/auxv fake file provided by the target kernel contains the info.  

The auxv_parse function below does the work of interpreting the auxv block
(from a core file's NT_AUXV/.auxv or from /proc/PID/auxv).  That little bit
of code is about right as it is.  The issues are when to call it.

Questions for the core file case:

1 Where should this call go in the order of operations?  

  I plopped the check in the middle of core_open because it seemed like it
  ought to come between the bfd opening and the register diddling that
  includes some calls about the grokking of the stack frame.  I don't know
  how loading a symfile interacts with that diddling.  Would it work to
  have the symbol_file_add_from_memory done after core_open?

2 Where should this support go in the target/generic code split?

  This code, and the need for it, is Linux-specific but not machine-specific.
  Linux 2.6 currently requires it on x86, IA64, and AMD64 (in both native and
  IA32 emulation versions).  The user-level support for the preloaded DSO
  image is machine-independent in the glibc implementation; no other Linux
  platform will overload the AT_SYSINFO_EHDR tag value for another purpose.
  I would like to have this implemented in gdb in a place that doesn't
  require duplication for the three existing platforms requiring the support,
  and will cover any other Linux target where kernels start using the same
  feature.  I don't see any obvious place like a common linux-tdep.c; where
  is the right place?  Should it be a different to_core_open hook that wraps
  the generic one?  Or maybe extend struct core_fns?  (But core_fns is
  redefined only in machine-specific files, and it appears inconsistently
  so--sometimes in *-nat.c and sometimes in *-tdep.c; what's the story?)

3 When and how should I unload the symbols on detaching from the core file?

  The solib symbols are cleared in core_close from what I can see.
  Is that the right spot to drop the symfile added from reading NT_AUXV?
  How do I clear it all out properly?  Do I just call free_objfile?
  Is remove_target_sections required as clear_solib does?

Similar questions for the live process case:

4 Where to make the call?

  The patch below does it in linux-nat.c's child_post_attach.  That makes
  it work for attach, but it is probably the wrong place.  I really have
  no idea where the right place to insert this is for the "run" case.  It
  needs to happen after the break-on-exec, the same time you would first
  insert breakpoints in the program.  Where is the right place to make
  that happen?  Is there one place that's right for both run and attach?

5 Same as #2, in context.

  linux-nat.c seems like it ought to be the right source file for the
  /proc parsing, or perhaps linux-proc.c; the auxv_parse function
  (renamed) should be shared between the core and live handling cases, it
  belongs in a linux-tdep sort of file logically.  

6 Same as #3, in context.

  I can't figure out where things get cleared out when a process dies or
  you detach.  Do they?  I see objfile_purge_solibs is called from
  run_command.  I think that will get the symfile I create.  Is that
  sufficient?  Do solibs get cleared on detach/attach?



Thanks,
Roland


Index: corelow.c
===================================================================
RCS file: /cvs/src/src/gdb/corelow.c,v
retrieving revision 1.30
diff -p -b -u -r1.30 corelow.c
--- corelow.c	21 Sep 2003 01:26:44 -0000	1.30
+++ corelow.c	3 Oct 2003 05:39:55 -0000
@@ -252,6 +252,63 @@ add_to_thread_list (bfd *abfd, asection 
     inferior_ptid = pid_to_ptid (thread_id);	/* Yes, make it current */
 }
 
+#include <elf/common.h>
+#include <elf/external.h>
+
+int
+auxv_parse (bfd *abfd, char *contents, bfd_size_type size, int from_tty)
+{
+  bfd_vma sysinfo_ehdr = 0;
+
+  switch (bfd_arch_bits_per_address (abfd))
+    {
+    default:
+      return 0;
+
+    case 32:
+      {
+	Elf32_External_Auxv *av;
+	for (av = (Elf32_External_Auxv *) contents;
+	     (char *) av < contents + size;
+	     ++av)
+	  {
+	    const bfd_vma type = bfd_get_32 (abfd, av->a_type);
+	    if (type == AT_NULL)
+	      break;
+	    if (type == AT_SYSINFO_EHDR)
+	      {
+		sysinfo_ehdr = bfd_get_32 (abfd, av->a_val);
+		break;
+	      }
+	  }
+	break;
+      }
+    case 64:
+      {
+	Elf64_External_Auxv *av;
+	for (av = (Elf64_External_Auxv *) contents;
+	     (char *) av < contents + size;
+	     ++av)
+	  {
+	    const bfd_vma type = bfd_get_64 (abfd, av->a_type);
+	    if (type == AT_NULL)
+	      break;
+	    if (type == AT_SYSINFO_EHDR)
+	      {
+		sysinfo_ehdr = bfd_get_64 (abfd, av->a_val);
+		break;
+	      }
+	  }
+	break;
+      }
+    }
+
+  if (sysinfo_ehdr != 0)
+    (void) symbol_file_add_from_memory (abfd, sysinfo_ehdr, from_tty);
+
+  return 1;
+}
+
 /* This routine opens and sets up the core file bfd.  */
 
 static void
@@ -264,6 +321,7 @@ core_open (char *filename, int from_tty)
   bfd *temp_bfd;
   int ontop;
   int scratch_chan;
+  asection *section;
 
   target_preopen (from_tty);
   if (!filename)
@@ -344,6 +402,22 @@ core_open (char *filename, int from_tty)
     printf_filtered ("Program terminated with signal %d, %s.\n", siggy,
 		     target_signal_to_string (target_signal_from_host (siggy)));
 
+  section = bfd_get_section_by_name (core_bfd, ".auxv");
+  if (section != NULL)
+    {
+      bfd_size_type size;
+      char *contents;
+      size = bfd_section_size (core_bfd, section);
+      contents = alloca (size);
+      if (! bfd_get_section_contents (core_bfd, section, contents,
+				      (file_ptr) 0, size))
+	warning ("Couldn't read NT_AUXV note in core file.");
+      else
+	{
+	  auxv_parse (core_bfd, contents, size, from_tty);
+	}
+    }
+
   /* Build up thread list from BFD sections. */
 
   init_thread_list ();
Index: linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-nat.c,v
retrieving revision 1.5
diff -p -b -u -r1.5 linux-nat.c
--- linux-nat.c	17 Aug 2003 20:17:02 -0000	1.5
+++ linux-nat.c	3 Oct 2003 05:39:56 -0000
@@ -24,6 +24,7 @@
 
 #include "gdb_wait.h"
 #include <sys/ptrace.h>
+#include <fcntl.h>
 
 #include "linux-nat.h"
 
@@ -234,10 +235,30 @@ linux_enable_event_reporting (ptid_t pti
   ptrace (PTRACE_SETOPTIONS, pid, 0, options);
 }
 
+static void
+linux_add_sysinfo_symbols (int pid)
+{
+  extern bfd *exec_bfd;		/* exec.c */
+  char filename[64];
+  int fd;
+  char contents[1024];
+  int size;
+
+  sprintf (filename, "/proc/%d/auxv", pid);
+  fd = open (filename, O_RDONLY);
+  if (fd < 0)
+    return;
+  size = read (fd, contents, sizeof contents);
+  close (fd);
+
+  auxv_parse (exec_bfd, contents, size, 0);
+}
+
 void
 child_post_attach (int pid)
 {
   linux_enable_event_reporting (pid_to_ptid (pid));
+  linux_add_sysinfo_symbols (pid);
 }
 
 void

Re: unwind support for Linux 2.6 vsyscall DSO

[Jim Blandy]

Roland McGrath <roland@redhat.com> writes:
> Questions for the core file case:
> 
> 1 Where should this call go in the order of operations?  
> 
>   I plopped the check in the middle of core_open because it seemed like it
>   ought to come between the bfd opening and the register diddling that
>   includes some calls about the grokking of the stack frame.  I don't know
>   how loading a symfile interacts with that diddling.  Would it work to
>   have the symbol_file_add_from_memory done after core_open?

It seems to me that it should be handled as much like other shared
libraries as possible.  So at the point where we load symbols for the
shared libraries that a core file references, we also want to load the
vsyscall library, if it exists.  Same for attach and run.

One approach might be for Linux to define its own linux-solib.h, which
#defines SOLIB_ADD and SOLIB_CLEAR to call linux-tdep.c functions that
do the standard dynamic linker stuff, but then check the auxv for an
AT_SYSINFO_EHDR entry and handle that, too.  That would make things
work pretty consistently for the core, attach, and run cases.

It seems to me that there should be a target vector method for
accessing the auxv information, since there's one native-specific way
to do it for attach and run, and a core-specific way to do it for core
files.  But it's Linux-specific information.  Well, actually, any OS
that uses the SYSV-style program invocation process is going to work
that way, so maybe it's justifiable.  I don't know.


> 2 Where should this support go in the target/generic code split?
> 
>   This code, and the need for it, is Linux-specific but not machine-specific.
>   Linux 2.6 currently requires it on x86, IA64, and AMD64 (in both native and
>   IA32 emulation versions).  The user-level support for the preloaded DSO
>   image is machine-independent in the glibc implementation; no other Linux
>   platform will overload the AT_SYSINFO_EHDR tag value for another purpose.
>   I would like to have this implemented in gdb in a place that doesn't
>   require duplication for the three existing platforms requiring the support,
>   and will cover any other Linux target where kernels start using the same
>   feature.  I don't see any obvious place like a common linux-tdep.c; where
>   is the right place?  Should it be a different to_core_open hook that wraps
>   the generic one?  Or maybe extend struct core_fns?  (But core_fns is
>   redefined only in machine-specific files, and it appears inconsistently
>   so--sometimes in *-nat.c and sometimes in *-tdep.c; what's the story?)

It seems to me this belongs in a new linux-tdep.c file.


Regarding the code:

Would it be appropriate to move auxv_parse into BFD?  If I remember
right, the dynamic linker parses the auxilliary vector into an array
indexed by AT_* values; GDB could call something like that, and then
just pick out the AT_SYSINFO_EHDR value pretty easily.

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> It seems to me that it should be handled as much like other shared
> libraries as possible.  So at the point where we load symbols for the
> shared libraries that a core file references, we also want to load the
> vsyscall library, if it exists.  Same for attach and run.

I certainly agree with this in principle.  But in practice I found that
other shared libraries are handled with complicated hair that it's
difficult to figure out exactly who calls and when, so I got scared.

> One approach might be for Linux to define its own linux-solib.h, which
> #defines SOLIB_ADD and SOLIB_CLEAR to call linux-tdep.c functions that
> do the standard dynamic linker stuff, but then check the auxv for an
> AT_SYSINFO_EHDR entry and handle that, too.  That would make things
> work pretty consistently for the core, attach, and run cases.

What can I see SOLIB_ADD gets called a lot, and every time it reconstructs
the inferior's list of objects and compares to gdb's list to see if there
are any new ones.  The vsyscall DSO is always there and is only possibly
changed by an exec, so it doesn't make sense to re-check its location a lot.
Should this SOLIB_ADD then just store whether it has checked yet and clear
that record in SOLIB_CLEAR?

> It seems to me that there should be a target vector method for
> accessing the auxv information, since there's one native-specific way
> to do it for attach and run, and a core-specific way to do it for core
> files.  But it's Linux-specific information.  Well, actually, any OS
> that uses the SYSV-style program invocation process is going to work
> that way, so maybe it's justifiable.  I don't know.

The notion of auxv information is at least ELF-specific, and in fact a
little more specific than that (a system need not use the canonical program
startup stack protocol to use the ELF file formats).  The style of getting
the auxv information is so far the same on every system I'm aware of that
provides a method, i.e. Solaris and Linux (now) both have NT_AUXV in core
files and /proc/PID/auxv for live processes.

> It seems to me this belongs in a new linux-tdep.c file.

Agreed.

> Would it be appropriate to move auxv_parse into BFD?  If I remember
> right, the dynamic linker parses the auxilliary vector into an array
> indexed by AT_* values; GDB could call something like that, and then
> just pick out the AT_SYSINFO_EHDR value pretty easily.

Though the AT_* values in use are a small set with few holes, it's actually
an arbitrary tag and not an index of any kind.  Nothing general-purpose can
assume the range of values is appropriate for an index, and no API should.
BFD is overkill for this (not that I'm saying BFD isn't overkill for
everything).  There is no variation in the format among ELF flavors, it's
just an even number of words in the format word size.  The very notion of
an auxilliary vector is ELF-specific; if a non-ELF backend had something
useful to export in the way of an auxilliary data from somewhere extraction
interface, it seems doubtful it would be a useful abstraction to call the
two the same thing in the frontend interface.  I don't have any objection
to moving the parsing portion out somewhere else, but making it any more
overblown than the few dozen lines of code it is would be pointless IMHO.

Re: unwind support for Linux 2.6 vsyscall DSO

[Jim Blandy]

Roland McGrath <roland@redhat.com> writes:
> > It seems to me that it should be handled as much like other shared
> > libraries as possible.  So at the point where we load symbols for the
> > shared libraries that a core file references, we also want to load the
> > vsyscall library, if it exists.  Same for attach and run.
> 
> I certainly agree with this in principle.  But in practice I found that
> other shared libraries are handled with complicated hair that it's
> difficult to figure out exactly who calls and when, so I got scared.
> 
> > One approach might be for Linux to define its own linux-solib.h, which
> > #defines SOLIB_ADD and SOLIB_CLEAR to call linux-tdep.c functions that
> > do the standard dynamic linker stuff, but then check the auxv for an
> > AT_SYSINFO_EHDR entry and handle that, too.  That would make things
> > work pretty consistently for the core, attach, and run cases.
> 
> What can I see SOLIB_ADD gets called a lot, and every time it reconstructs
> the inferior's list of objects and compares to gdb's list to see if there
> are any new ones.  The vsyscall DSO is always there and is only possibly
> changed by an exec, so it doesn't make sense to re-check its location a lot.
> Should this SOLIB_ADD then just store whether it has checked yet and clear
> that record in SOLIB_CLEAR?

I think that's what it would take.  Open to better ideas, I'm just
doing the best I can. :)

> > It seems to me that there should be a target vector method for
> > accessing the auxv information, since there's one native-specific way
> > to do it for attach and run, and a core-specific way to do it for core
> > files.  But it's Linux-specific information.  Well, actually, any OS
> > that uses the SYSV-style program invocation process is going to work
> > that way, so maybe it's justifiable.  I don't know.
> 
> The notion of auxv information is at least ELF-specific, and in fact a
> little more specific than that (a system need not use the canonical program
> startup stack protocol to use the ELF file formats).  The style of getting
> the auxv information is so far the same on every system I'm aware of that
> provides a method, i.e. Solaris and Linux (now) both have NT_AUXV in core
> files and /proc/PID/auxv for live processes.

When I say "target vector", I mean 'struct target_ops', not 'struct
gdbarch'.  That is, for core files you ask BFD for the .auxv section,
whereas for live processes you open /proc/PID/auxv.  The code dealing
with the vsyscall solib in the shared library handler (or whereever)
would just call target_get_auxilliary_vector, and the target stack
would decide where to look for it.

> > It seems to me this belongs in a new linux-tdep.c file.
> 
> Agreed.
> 
> > Would it be appropriate to move auxv_parse into BFD?  If I remember
> > right, the dynamic linker parses the auxilliary vector into an array
> > indexed by AT_* values; GDB could call something like that, and then
> > just pick out the AT_SYSINFO_EHDR value pretty easily.
> 
> Though the AT_* values in use are a small set with few holes, it's actually
> an arbitrary tag and not an index of any kind.  Nothing general-purpose can
> assume the range of values is appropriate for an index, and no API
> should.

Okay, maybe that's not the greatest API.

> BFD is overkill for this (not that I'm saying BFD isn't overkill for
> everything).  There is no variation in the format among ELF flavors, it's
> just an even number of words in the format word size.  The very notion of
> an auxilliary vector is ELF-specific; if a non-ELF backend had something
> useful to export in the way of an auxilliary data from somewhere extraction
> interface, it seems doubtful it would be a useful abstraction to call the
> two the same thing in the frontend interface.  I don't have any objection
> to moving the parsing portion out somewhere else, but making it any more
> overblown than the few dozen lines of code it is would be pointless IMHO.

Yeah, I had in mind another elf-specific BFD function, like the one
that reads the solib data from memory.  All I'm suggesting is, take
the code that you've got, move it into bfd, and call it
bfd_elf_auxilliary_vector_sysinfo_ehdr.

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> > Should this SOLIB_ADD then just store whether it has checked yet and clear
> > that record in SOLIB_CLEAR?
> 
> I think that's what it would take.  Open to better ideas, I'm just
> doing the best I can. :)

Ok.  I don't see a problem with this if the sequence of when SOLIB_ADD and
SOLIB_CLEAR will be called is correct.  That is, SOLIB_ADD after core load,
after attach, or after the break-on-exec (second one) from run, and
SOLIB_CLEAR some appropriate time for unloading symbols.  It's important
that SOLIB_ADD not be called too early in the run case, i.e. before the
second exec so that the inferior's state is not yet as it will be.
Can I rely on that not happening?

> When I say "target vector", I mean 'struct target_ops', not 'struct
> gdbarch'.  

I understood you.  My only point was that the notion of such a hook is
ELF-specific and so perhaps that says something about whether an addition
of a hook to the generic target_ops structure is appropriate.

> Yeah, I had in mind another elf-specific BFD function, like the one
> that reads the solib data from memory.  All I'm suggesting is, take
> the code that you've got, move it into bfd, and call it
> bfd_elf_auxilliary_vector_sysinfo_ehdr.

Ok.  A function quite that specific seems really pointless to me.  Some
sort of `bfd_elf_decode_auxv' that either gives an AT_* value to search
for, or translates one or all entries into Elf_Internal_Auxv format seems
more appropriate.  e.g.:

bfd_error bfd_elf_decode_auxv (bfd *, char **data, bfd_size_type *nbytes,
			       Elf_Internal_Auxv *element);

used as in:

	{
	  Elf_Internal_Auxv av;
	  char *p = contents;
	  bfd_size_type n = contents_size;
	  while (bfd_elf_decode_auxv (abfd, &p, &n, &av) == bfd_error_no_error)
	    if (av.a_type == AT_SYSINFO_EHDR)
	      {
		do_stuff (av.a_val);
		break;
	      }
	}

or:

bfd_error bfd_elf_auxv_extract (bfd *, char *data, bfd_size_type nbytes,
			        bfd_vma tag, bfd_vma *val);

used as in:

	{
	  bfd_vma val;
	  if (bfd_elf_auxv_extract (abfd, contents, contents_size,
				    AT_SYSINFO_EHDR, &val) == bfd_error_no_error)
	    do_stuff (av.a_val);
	}


Thanks,
Roland

Re: unwind support for Linux 2.6 vsyscall DSO

[Daniel Jacobowitz]

On Sat, Oct 04, 2003 at 01:27:06PM -0700, Roland McGrath wrote:
> > > Should this SOLIB_ADD then just store whether it has checked yet and clear
> > > that record in SOLIB_CLEAR?
> > 
> > I think that's what it would take.  Open to better ideas, I'm just
> > doing the best I can. :)
> 
> Ok.  I don't see a problem with this if the sequence of when SOLIB_ADD and
> SOLIB_CLEAR will be called is correct.  That is, SOLIB_ADD after core load,
> after attach, or after the break-on-exec (second one) from run, and
> SOLIB_CLEAR some appropriate time for unloading symbols.  It's important
> that SOLIB_ADD not be called too early in the run case, i.e. before the
> second exec so that the inferior's state is not yet as it will be.
> Can I rely on that not happening?

Yes, since this is when solibs are normally loaded anyway.

An issue is whether it gets called early enough, i.e. before the
dynamic linker breakpoint is hit, or at all for static applications. 
We'll have to see.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> Yes, since this is when solibs are normally loaded anyway.

Ok.  I was concerned that it might just try to look at the shell, where its
symbols wouldn't match and it would just ignore those errors.  Getting the
auxv information will always work, but could be wrong information if there
is another exec, so that would not be as resilient as SOLIB_ADD now is.
To wit, infrun.c:1352:

    case TARGET_WAITKIND_LOADED:
      /* Ignore gracefully during startup of the inferior, as it
         might be the shell which has just loaded some objects,
         otherwise add the symbols for the newly loaded objects.  */

If this comment is accurate and I'm understanding its context correctly,
the problem I just described is in fact a problem.

> An issue is whether it gets called early enough, i.e. before the
> dynamic linker breakpoint is hit, or at all for static applications. 
> We'll have to see.

Indeed, it doesn't look to me like it is, except for the attach case.
Aside from attach_command, all the SOLIB_ADD calls in infrun.c are
conditional on some kind of "shlib loaded" event.  I am presuming those
don't happen at exec.  

Incidentally, I'm also noticing another case we haven't been discussing
directly.  In addition to the core, attach, and run scenarios, there is
"follow exec" apparently.  I ran across this in looking for the earliest
places insert_breakpoints is called, which seems like around the same time
the auxv examination and vsyscall DSO setup should be done.


Thanks,
Roland

Re: unwind support for Linux 2.6 vsyscall DSO

[Daniel Jacobowitz]

On Sat, Oct 04, 2003 at 03:01:09PM -0700, Roland McGrath wrote:
> > Yes, since this is when solibs are normally loaded anyway.
> 
> Ok.  I was concerned that it might just try to look at the shell, where its
> symbols wouldn't match and it would just ignore those errors.  Getting the
> auxv information will always work, but could be wrong information if there
> is another exec, so that would not be as resilient as SOLIB_ADD now is.
> To wit, infrun.c:1352:
> 
>     case TARGET_WAITKIND_LOADED:
>       /* Ignore gracefully during startup of the inferior, as it
>          might be the shell which has just loaded some objects,
>          otherwise add the symbols for the newly loaded objects.  */
> 
> If this comment is accurate and I'm understanding its context correctly,
> the problem I just described is in fact a problem.

It is not accurate.  TARGET_WAITKIND_LOADED isn't currenty used for
non HP/UX targets.

> > An issue is whether it gets called early enough, i.e. before the
> > dynamic linker breakpoint is hit, or at all for static applications. 
> > We'll have to see.
> 
> Indeed, it doesn't look to me like it is, except for the attach case.
> Aside from attach_command, all the SOLIB_ADD calls in infrun.c are
> conditional on some kind of "shlib loaded" event.  I am presuming those
> don't happen at exec.  

We don't want to SOLIB_ADD before the dynamic linker has gotten a
chance to initialize, I suspect.  Let me think about it; let's fix the
dynamic case first.

> Incidentally, I'm also noticing another case we haven't been discussing
> directly.  In addition to the core, attach, and run scenarios, there is
> "follow exec" apparently.  I ran across this in looking for the earliest
> places insert_breakpoints is called, which seems like around the same time
> the auxv examination and vsyscall DSO setup should be done.

Don't worry about follow_exec.  It's currently broken and needs some
serious redesigning.  I haven't had a chance to revisit this since I
fixed fork following.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: unwind support for Linux 2.6 vsyscall DSO

[Jim Blandy]

Roland McGrath <roland@redhat.com> writes:

> > > Should this SOLIB_ADD then just store whether it has checked yet and clear
> > > that record in SOLIB_CLEAR?
> > 
> > I think that's what it would take.  Open to better ideas, I'm just
> > doing the best I can. :)
> 
> Ok.  I don't see a problem with this if the sequence of when SOLIB_ADD and
> SOLIB_CLEAR will be called is correct.  That is, SOLIB_ADD after core load,
> after attach, or after the break-on-exec (second one) from run, and
> SOLIB_CLEAR some appropriate time for unloading symbols.  It's important
> that SOLIB_ADD not be called too early in the run case, i.e. before the
> second exec so that the inferior's state is not yet as it will be.
> Can I rely on that not happening?

I think you can rely on SOLIB_ADD not being called too early.  It
would be a bug if we ever called it before the shell execs the
executable under debug, because we use the VMA of the .dynamic
section of the executable file to find the dynamic structure in the
inferior's memory anyway.  We couldn't even find the shell's shared
library list.


> > When I say "target vector", I mean 'struct target_ops', not 'struct
> > gdbarch'.  
> 
> I understood you.  My only point was that the notion of such a hook is
> ELF-specific and so perhaps that says something about whether an addition
> of a hook to the generic target_ops structure is appropriate.

I'm wondering how the core / live process distinction gets made when
we need to find the auxilliary vector.  The code reading the vsyscall
library from memory should just read memory from whatever target is
there, and it seems like the aux vector should work the same way.

> Ok.  A function quite that specific seems really pointless to me.  Some
> sort of `bfd_elf_decode_auxv' that either gives an AT_* value to search
> for, or translates one or all entries into Elf_Internal_Auxv format seems
> more appropriate.  e.g.:
> 
> bfd_error bfd_elf_decode_auxv (bfd *, char **data, bfd_size_type *nbytes,
> 			       Elf_Internal_Auxv *element);
> 
> used as in:
> 
> 	{
> 	  Elf_Internal_Auxv av;
> 	  char *p = contents;
> 	  bfd_size_type n = contents_size;
> 	  while (bfd_elf_decode_auxv (abfd, &p, &n, &av) == bfd_error_no_error)
> 	    if (av.a_type == AT_SYSINFO_EHDR)
> 	      {
> 		do_stuff (av.a_val);
> 		break;
> 	      }
> 	}
> 
> or:
> 
> bfd_error bfd_elf_auxv_extract (bfd *, char *data, bfd_size_type nbytes,
> 			        bfd_vma tag, bfd_vma *val);
> 
> used as in:
> 
> 	{
> 	  bfd_vma val;
> 	  if (bfd_elf_auxv_extract (abfd, contents, contents_size,
> 				    AT_SYSINFO_EHDR, &val) == bfd_error_no_error)
> 	    do_stuff (av.a_val);
> 	}

The latter seems nicer to me.

Re: unwind support for Linux 2.6 vsyscall DSO

[Elena Zannoni]

Jim Blandy writes:
 > 
 > Roland McGrath <roland@redhat.com> writes:
 > 
 > > BFD is overkill for this (not that I'm saying BFD isn't overkill for
 > > everything).  There is no variation in the format among ELF flavors, it's
 > > just an even number of words in the format word size.  The very notion of
 > > an auxilliary vector is ELF-specific; if a non-ELF backend had something
 > > useful to export in the way of an auxilliary data from somewhere extraction
 > > interface, it seems doubtful it would be a useful abstraction to call the
 > > two the same thing in the frontend interface.  I don't have any objection
 > > to moving the parsing portion out somewhere else, but making it any more
 > > overblown than the few dozen lines of code it is would be pointless IMHO.
 > 
 > Yeah, I had in mind another elf-specific BFD function, like the one
 > that reads the solib data from memory.  All I'm suggesting is, take
 > the code that you've got, move it into bfd, and call it
 > bfd_elf_auxilliary_vector_sysinfo_ehdr.

I disagree with moving the read of auxv to bfd. Gdb already processes
plenty of /proc files (on Solaris using 2 interfaces), and has target
methods defined for these, so I would treat the auxv case just like the
others.

elena

Re: unwind support for Linux 2.6 vsyscall DSO

[Elena Zannoni]

Roland McGrath writes:
 > In the past (during this spring and summer) there were some discussions
 > about the need to find unwind info in the vsyscall DSO image implicitly
 > loaded in processes on Linux 2.5/2.6 on some platforms.  I honestly don't
 > recall which mailing lists this was on.  If people are not clear on the
 > issues, I can try to dig up the various summaries of the details I have
 > posted before.  This was tabled for a while when I had other priorities
 > since it didn't turn out to be an issue with any kernel version used by
 > Red Hat production systems.
 > 
 > Now Linux 2.6 is getting firmed up, and it's time to revisit this.  On
 > Linux 2.6 kernels, backtraces from programs stopped in system calls do not
 > work using current glibc on x86 and AMD64 machines.  The same issue exists
 > on IA64 in Linux 2.6, and glibc will before long make use of the feature so
 > that system call backtraces need the same solutions for IA64.
 > 
 > My changes to export the auxv information in core dumps and /proc are now
 > making their way into Linux 2.6, and this gives us the tools we need to
 > solve the problem in gdb.

Ok, reading the thread, I see that you are running pretty much into
the same problems I am running into for PIE support.  What kind of
information is exacty exported into the auxv file?  I am wondering if
you also have the entry point of the program there (AT_ENTRY, looking
at the Solaris auxv.h), because if so it may change my current way of
looking at PIE, where I am taking the info from the /proc/pid/map
file, which is not saved in the core file, I think, while auxv is.

Anyway, this issue aside, there is a target method in gdb to process
the various entries in the map file. I think it would be appropriate
to translate that into something similar for reading the auxv
file. Have a look at target_find_memory_regions. It is defined for
linux in linux-proc.c, and for Solaris in procfs.c, and for fbsd as
well. It is just an iterator over the entries in the map file, but you
get the general idea. There is a bug in there as it is not defined
properly for the core target, while in this case it obviously should
be. This way it could be easily extended for Solaris, etc too, some
day.

For the core file case, look at
gcore.c:objfile_find_memory_regions(). This is the one that fiddles
with remote/core cases. You are in an analogous situation here with
reading from bfd instead of /proc.

Of course, the target_find_memory_regions() function is called only by
the gcore command, which is quite different from what you need to do.

I agree that treating this new information as much as possible as a
shared library will make our life easier, because all the checks are
done in the right spots already. I have some solib debug code that
Kevin approved for mainline, I'll commit it now, if that can be of
help in seeing what happens when shlibs are loaded.

elena

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> Ok, reading the thread, I see that you are running pretty much into
> the same problems I am running into for PIE support.  What kind of
> information is exacty exported into the auxv file?  I am wondering if
> you also have the entry point of the program there (AT_ENTRY, looking
> at the Solaris auxv.h), because if so it may change my current way of
> looking at PIE, where I am taking the info from the /proc/pid/map
> file, which is not saved in the core file, I think, while auxv is.

Try "LD_SHOW_AUXV=1 /bin/true" (i.e. put that in the environment of any
program--it's checked by the dynamic linker).  That shows you all the
information that the kernel supplies in this fashion (you have to be using
Linux 2.6 to see AT_SYSINFO and AT_SYSINFO_EHDR in there).  AT_ENTRY is
certainly there--that's how the dynamic linker knows where to jump to start
the program after initialization.  There is also AT_PHDR, which is another
thing that gives you the runtime address of something that you know the
link-time address of (PT_PHDR).  If access to AT_ENTRY alone doesn't solve
your problem with PIE, I'd like to help figure out what else it is you
need; so please raise that in a separate thread CC'd to me.

> Anyway, this issue aside, there is a target method in gdb to process the
> various entries in the map file. I think it would be appropriate to
> translate that into something similar for reading the auxv file.

Ok.  This is what Jim suggested too.  Do you have a function signature in mind?
Perhaps:

  int (*to_get_auxv_data) (char **data, size_t *size);

that fills in a malloc'd block.  (The data will be examined briefly and
thrown away, but malloc seems like the simplest clean interface to use.)

> I agree that treating this new information as much as possible as a
> shared library will make our life easier, because all the checks are
> done in the right spots already. 

and Jim wrote:

> I think you can rely on SOLIB_ADD not being called too early.  It would
> be a bug if we ever called it before the shell execs the executable under
> debug, because we use the VMA of the .dynamic section of the executable
> file to find the dynamic structure in the inferior's memory anyway.  We
> couldn't even find the shell's shared library list.

Right, it would fail to find any list at all.  If it treats that as "empty
list" then this won't be a change from before and so it's a harmless no-op.
Are we sure that is not what is happening now?  If it is, it's harmless now
but having the auxv-reading done too early would not be harmless.

> I disagree with moving the read of auxv to bfd. Gdb already processes
> plenty of /proc files (on Solaris using 2 interfaces), and has target
> methods defined for these, so I would treat the auxv case just like the
> others.

What we have been discussing most recently is only a BFD utility function
to examine raw auxv blocks that have already been read in somehow.
i.e., a trivial helper function that these target methods would use.
It doesn't matter to me whether this is in bfd/elf.c or gdb/elfread.c.



Thanks,
Roland

Re: unwind support for Linux 2.6 vsyscall DSO

[Elena Zannoni]

Roland McGrath writes:
 > > Ok, reading the thread, I see that you are running pretty much into
 > > the same problems I am running into for PIE support.  What kind of
 > > information is exacty exported into the auxv file?  I am wondering if
 > > you also have the entry point of the program there (AT_ENTRY, looking
 > > at the Solaris auxv.h), because if so it may change my current way of
 > > looking at PIE, where I am taking the info from the /proc/pid/map
 > > file, which is not saved in the core file, I think, while auxv is.
 > 
 > Try "LD_SHOW_AUXV=1 /bin/true" (i.e. put that in the environment of any
 > program--it's checked by the dynamic linker).  That shows you all the
 > information that the kernel supplies in this fashion (you have to be using
 > Linux 2.6 to see AT_SYSINFO and AT_SYSINFO_EHDR in there).  AT_ENTRY is
 > certainly there--that's how the dynamic linker knows where to jump to start
 > the program after initialization.  There is also AT_PHDR, which is another
 > thing that gives you the runtime address of something that you know the
 > link-time address of (PT_PHDR).  If access to AT_ENTRY alone doesn't solve
 > your problem with PIE, I'd like to help figure out what else it is you
 > need; so please raise that in a separate thread CC'd to me.
 > 

ok.

 > > Anyway, this issue aside, there is a target method in gdb to process the
 > > various entries in the map file. I think it would be appropriate to
 > > translate that into something similar for reading the auxv file.
 > 
 > Ok.  This is what Jim suggested too.  Do you have a function signature in mind?
 > Perhaps:
 > 
 >   int (*to_get_auxv_data) (char **data, size_t *size);
 > 
 > that fills in a malloc'd block.  (The data will be examined briefly and
 > thrown away, but malloc seems like the simplest clean interface to use.)
 > 

There should be an iterator over the entries in the /proc/pid/auxv
file with a callback that processes each entry. So that the iterator
could be used not just for finding the AT_SYSINFO_EHDR entry. I think
the number of iterations would be your size_t above divided by the
size of an auxv_t or something similar.

For instance something like the one for solaris:

 * Call a callback function once for each mapping, passing it the mapping,
 * an optional secondary callback function, and some optional opaque data.
 * Quit and return the first non-zero value returned from the callback.
 *
 * Arguments:
 *   pi   -- procinfo struct for the process to be mapped.
 *   func -- callback function to be called by this iterator.
 *   data -- optional opaque data to be passed to the callback function.
 *   child_func -- optional secondary function pointer to be passed
 *                 to the child function.
 *
 * Return: First non-zero return value from the callback function, 
 *         or zero.
int
iterate_over_mappings (procinfo *pi, int (*child_func) (), void *data, 
		       int (*func) (struct prmap *map, 
				    int (*child_func) (), 
				    void *data))

In this case, instead of a prmap structure we would have an auxv_t
structure, or something like that. Doesn't need to be that complicated
as the one above. The linux one for reading MAP is a bit simpler.


 > > I agree that treating this new information as much as possible as a
 > > shared library will make our life easier, because all the checks are
 > > done in the right spots already. 
 > 
 > and Jim wrote:
 > 
 > > I think you can rely on SOLIB_ADD not being called too early.  It would
 > > be a bug if we ever called it before the shell execs the executable under
 > > debug, because we use the VMA of the .dynamic section of the executable
 > > file to find the dynamic structure in the inferior's memory anyway.  We
 > > couldn't even find the shell's shared library list.
 > 
 > Right, it would fail to find any list at all.  If it treats that as "empty
 > list" then this won't be a change from before and so it's a harmless no-op.
 > Are we sure that is not what is happening now?  If it is, it's harmless now
 > but having the auxv-reading done too early would not be harmless.
 > 

The first thing that happens is that the breakpoint inserted at the
dynamic linker is hit, at which point gdb gets to add the shlibs.
For instance with the debug output enabled:

[...start up gdb...]
(gdb) set debug solib 1
(gdb) b main
Breakpoint 1 at 0x80484ce: file /scratch/ezannoni/pie-work/src/gdb/testsuite/gdb.base/break.c, line 75.
(gdb) r
Starting program: /scratch/ezannoni/pie-work/native/gdb/testsuite/gdb.base/break 
enable_break: search for .interp in /scratch/ezannoni/pie-work/native/gdb/testsuite/gdb.base/break
enable_break: opening /lib/ld-linux.so.2
elf_locate_base: DT_DEBUG entry has value 0x0
svr4_current_sos: no DT_DEBUG found
enable_break: solib bp set
<<<<<<<<SOLIB BP HIT>>>>>>>>
elf_locate_base: DT_DEBUG entry has value 0x400136bc
svr4_current_sos: Processing DSO: /lib/i686/libm.so.6
svr4_current_sos: Processing DSO: /lib/i686/libc.so.6
svr4_current_sos: Processing DSO: /lib/ld-linux.so.2
svr4_current_sos: Processing DSO: /lib/i686/libm.so.6
svr4_current_sos: Processing DSO: /lib/i686/libc.so.6
svr4_current_sos: Processing DSO: /lib/ld-linux.so.2
svr4_current_sos: Processing DSO: /lib/i686/libm.so.6
svr4_current_sos: Processing DSO: /lib/i686/libc.so.6
svr4_current_sos: Processing DSO: /lib/ld-linux.so.2

I think we are safe here.

 > > I disagree with moving the read of auxv to bfd. Gdb already processes
 > > plenty of /proc files (on Solaris using 2 interfaces), and has target
 > > methods defined for these, so I would treat the auxv case just like the
 > > others.
 > 
 > What we have been discussing most recently is only a BFD utility function
 > to examine raw auxv blocks that have already been read in somehow.
 > i.e., a trivial helper function that these target methods would use.
 > It doesn't matter to me whether this is in bfd/elf.c or gdb/elfread.c.
 > 
 > 

Since we need the iterator method, this read/parse becomes a very
small piece and fits nicely in linux-proc.c in the live inferior
case. For the corefile/remote case, you would ask bfd for the .auxv
section of the core file and parse that in order to get an element of
the vector and this is also something that can be in gdb, unless you
want to reuse that in some other tool.

elena


 > 
 > Thanks,
 > Roland

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> There should be an iterator over the entries in the /proc/pid/auxv
> file with a callback that processes each entry. So that the iterator
> could be used not just for finding the AT_SYSINFO_EHDR entry. 

Ok, an iterator interface is fine with me, just marginally less efficient
than the searcher when only one tag is actually used (and more efficient if
many tags are used).  (I had not proposed any function that would be useful
solely for AT_SYSINFO_EHDR, though that was one of Jim's early
suggestions.)  If others agree this is the right interface for a target_ops
addition, I will write that patch.

> I think the number of iterations would be your size_t above divided by
> the size of an auxv_t or something similar.

Indeed.

> The first thing that happens is that the breakpoint inserted at the
> dynamic linker is hit, at which point gdb gets to add the shlibs.

Obviously that's not the first thing, since inserting the breakpoint in the
dynamic linker happens before that.  It's ideal to do the vsyscall DSO
setup before letting the dynamic linker run at all.  That way you have that
information in case you get a signal in the early part of dynamic linker
startup, or attach to a process that is for some reason blocked in a system
call in that early stage, and want to see a backtrace to understand the
state.

> enable_break: search for .interp in /scratch/ezannoni/pie-work/native/gdb/testsuite/gdb.base/break
> enable_break: opening /lib/ld-linux.so.2
> elf_locate_base: DT_DEBUG entry has value 0x0
> svr4_current_sos: no DT_DEBUG found

I don't see your debugging code in mainline gdb and so I can only guess
what these messages mean in terms of the code. 

Are you sure this doesn't mean it looked at the sh process before it
exec'd?  It wouldn't find anything there because it would be looking for
DT_DEBUG from the .dynamic address of the "break" binary and sh's layout is
different (so it's reading arbitrary other data and not finding the tag).

> Since we need the iterator method, this read/parse becomes a very
> small piece and fits nicely in linux-proc.c in the live inferior
> case. For the corefile/remote case, you would ask bfd for the .auxv
> section of the core file and parse that in order to get an element of
> the vector and this is also something that can be in gdb, unless you
> want to reuse that in some other tool.

We are all clear on the steps that need to be performed.  The part that
parses the format and deals with the target wordsize question and
byteswapping, is common work between the live and core cases that might use
a shared function rather than duplicative source code.  That is what we
have been discussing.

You said "corefile/remote case", but looking for a .auxv section applies
only to core files.  I don't think we have discussed the remote case.  It
would require the remote stub reading the local /proc/PID/auxv file and
giving the information back to gdb.  I'm not aware of anything in the
remote protocol to allow that.


Thanks,
Roland

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> > There should be an iterator over the entries in the /proc/pid/auxv
> > file with a callback that processes each entry. So that the iterator
> > could be used not just for finding the AT_SYSINFO_EHDR entry. 
> 
> Ok, an iterator interface is fine with me, just marginally less efficient
> than the searcher when only one tag is actually used (and more efficient if
> many tags are used).  (I had not proposed any function that would be useful
> solely for AT_SYSINFO_EHDR, though that was one of Jim's early
> suggestions.)  If others agree this is the right interface for a target_ops
> addition, I will write that patch.

Actually, I think this is not as useful an interface as one that fetches
the whole block for you.  There is another use for this call besides the
Linux-specific AT_SYSINFO_EHDR check: gcore.  We want gcore to produce
NT_AUXV notes in core dumps so that those core dumps can be used to extract
whatever AT_* information we could extract from core dumps written by a kernel.

This is easy to add either way, but is cleaner, simpler, and more efficient
if it just writes the whole block uninterpreted than if it dissects and
reassembles it.

Re: unwind support for Linux 2.6 vsyscall DSO

[Elena Zannoni]

Roland McGrath writes:
 > > > There should be an iterator over the entries in the /proc/pid/auxv
 > > > file with a callback that processes each entry. So that the iterator
 > > > could be used not just for finding the AT_SYSINFO_EHDR entry. 
 > > 
 > > Ok, an iterator interface is fine with me, just marginally less efficient
 > > than the searcher when only one tag is actually used (and more efficient if
 > > many tags are used).  (I had not proposed any function that would be useful
 > > solely for AT_SYSINFO_EHDR, though that was one of Jim's early
 > > suggestions.)  If others agree this is the right interface for a target_ops
 > > addition, I will write that patch.
 > 
 > Actually, I think this is not as useful an interface as one that fetches
 > the whole block for you.  There is another use for this call besides the
 > Linux-specific AT_SYSINFO_EHDR check: gcore.  We want gcore to produce
 > NT_AUXV notes in core dumps so that those core dumps can be used to extract
 > whatever AT_* information we could extract from core dumps written by a kernel.
 > 

It is useful if you want to apply a specific function to the entries
of the auxv vectors in a generic way while iterating. There are plenty
of other examples in gdb and bfd where this interface is used, albeit
it may not be the most efficient. I think you could still write an
iterator because it will be needed.

 > This is easy to add either way, but is cleaner, simpler, and more efficient
 > if it just writes the whole block uninterpreted than if it dissects and
 > reassembles it.

For the corefile case.

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> It is useful if you want to apply a specific function to the entries
> of the auxv vectors in a generic way while iterating. There are plenty
> of other examples in gdb and bfd where this interface is used, albeit
> it may not be the most efficient. I think you could still write an
> iterator because it will be needed.

I understand.  I would prefer a block-reading interface in the target
vector (e.g. something similar to target_read_aux_vector as in the patch I
posted) and a utility function that is an iterator applied to the block.
Do you see a problem with that?  Or do you think that the conversion from
target width and byte order to host format and back is desireable in some
way?  I don't feel strongly about this.

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> I understand.  I would prefer a block-reading interface in the target
> vector (e.g. something similar to target_read_aux_vector as in the patch I
> posted) and a utility function that is an iterator applied to the block.

Note one reason I prefer this is that the utility function is needed
regardless.  If the to_read_aux_vector hook is an iterator, then each
implementation will use this utility function on the contents it's read in.
If the to_read_aux_vector hook returns the whole block, then some of the
callers (not those doing core file writing) will use this utility function
on the contents supplied by the target hook.  The code that needs to be
shared (or duplicated) is the same either way.

Re: unwind support for Linux 2.6 vsyscall DSO

[Andrew Cagney]

>> > There should be an iterator over the entries in the /proc/pid/auxv
>> > file with a callback that processes each entry. So that the iterator
>> > could be used not just for finding the AT_SYSINFO_EHDR entry. 
> 
>> 
>> Ok, an iterator interface is fine with me, just marginally less efficient
>> than the searcher when only one tag is actually used (and more efficient if
>> many tags are used).  (I had not proposed any function that would be useful
>> solely for AT_SYSINFO_EHDR, though that was one of Jim's early
>> suggestions.)  If others agree this is the right interface for a target_ops
>> addition, I will write that patch.
> 
> 
> Actually, I think this is not as useful an interface as one that fetches
> the whole block for you.  There is another use for this call besides the
> Linux-specific AT_SYSINFO_EHDR check: gcore.  We want gcore to produce
> NT_AUXV notes in core dumps so that those core dumps can be used to extract
> whatever AT_* information we could extract from core dumps written by a kernel.
> 
> This is easy to add either way, but is cleaner, simpler, and more efficient
> if it just writes the whole block uninterpreted than if it dissects and
> reassembles it.

For this to work, there will need to be mechanisms that:

- unpack an architecture's auxv
- pack an architecture's auxv
- transport the auxv from the target, to GDB.

The problem then is how to arrange these mechanisms so that they 
integrate well enough to work both native and cross (i386 on amd64 is 
considered a cross), be consistent with other gdb mechanisms and direction:

target vector xfers via an iterator:
- the low native code would be using the unpack method
- the PIE and VSYSCALL code would be very simple
- the CORE file code would need the pack method
- the low remote could on-demand read the data

target vector xfers raw data:
- the low native code would be simple
- the PIE and VSYSCALL code would need to use the unpack method
- the CORE file code would just write out the data
- the low remote code would, either be locked into transfering raw 
bytes, or be forced to use the pack method

Also, ...

In my way earlier post, I also suggested "remote I/O' - a generic 
mechanism for accessing arbitrary target data.  Looking through the 
target vectore I see there is already "to_query()".  The original intent 
of to_query was to handle exactly this sort of problem - pushing data 
anonymously through the target vector.   The auxv fetch, with a large 
bit of a struggle, could even be implemented using to_query.

So?

I've strong reservations towards adding redundant functionality to the 
target vector.  However, I also note that the existing to_query method 
isn't sufficient.

So I can see either an iterator, or an update to to_query being added to 
the target vector.  Given that the iterator is a given, that might be 
the safest starting point - let the target maintainer go through and 
clean up to_query.

thoughts,
Andrew

Re: unwind support for Linux 2.6 vsyscall DSO

[Daniel Jacobowitz]

On Mon, Oct 06, 2003 at 11:53:20PM -0400, Andrew Cagney wrote:
> >>> There should be an iterator over the entries in the /proc/pid/auxv
> >>> file with a callback that processes each entry. So that the iterator
> >>> could be used not just for finding the AT_SYSINFO_EHDR entry. 
> >
> >>
> >>Ok, an iterator interface is fine with me, just marginally less efficient
> >>than the searcher when only one tag is actually used (and more efficient 
> >>if
> >>many tags are used).  (I had not proposed any function that would be 
> >>useful
> >>solely for AT_SYSINFO_EHDR, though that was one of Jim's early
> >>suggestions.)  If others agree this is the right interface for a 
> >>target_ops
> >>addition, I will write that patch.
> >
> >
> >Actually, I think this is not as useful an interface as one that fetches
> >the whole block for you.  There is another use for this call besides the
> >Linux-specific AT_SYSINFO_EHDR check: gcore.  We want gcore to produce
> >NT_AUXV notes in core dumps so that those core dumps can be used to extract
> >whatever AT_* information we could extract from core dumps written by a 
> >kernel.
> >
> >This is easy to add either way, but is cleaner, simpler, and more efficient
> >if it just writes the whole block uninterpreted than if it dissects and
> >reassembles it.
> 
> For this to work, there will need to be mechanisms that:
> 
> - unpack an architecture's auxv
> - pack an architecture's auxv
> - transport the auxv from the target, to GDB.
> 
> The problem then is how to arrange these mechanisms so that they 
> integrate well enough to work both native and cross (i386 on amd64 is 
> considered a cross), be consistent with other gdb mechanisms and direction:
> 
> target vector xfers via an iterator:
> - the low native code would be using the unpack method
> - the PIE and VSYSCALL code would be very simple
> - the CORE file code would need the pack method
> - the low remote could on-demand read the data

I think a pack method is overengineered.  Unlike, for instance,
register files, we never need to pack an arbitrary auxv array.
We're always just copying one that we've been given, exactly as-is.
I just see call for transport and query.

> target vector xfers raw data:
> - the low native code would be simple
> - the PIE and VSYSCALL code would need to use the unpack method
> - the CORE file code would just write out the data
> - the low remote code would, either be locked into transfering raw 
> bytes, or be forced to use the pack method
> 
> Also, ...
> 
> In my way earlier post, I also suggested "remote I/O' - a generic 
> mechanism for accessing arbitrary target data.  Looking through the 
> target vectore I see there is already "to_query()".  The original intent 
> of to_query was to handle exactly this sort of problem - pushing data 
> anonymously through the target vector.   The auxv fetch, with a large 
> bit of a struggle, could even be implemented using to_query.

Hmm, yes.  The only problem that I see is the buffer-sizing one.  A
traditional problem in our interfaces, I think; the remote code avoids
the issue delicately.

> So?
> 
> I've strong reservations towards adding redundant functionality to the 
> target vector.  However, I also note that the existing to_query method 
> isn't sufficient.
> 
> So I can see either an iterator, or an update to to_query being added to 
> the target vector.  Given that the iterator is a given, that might be 
> the safest starting point - let the target maintainer go through and 
> clean up to_query.

While I won't argue about an iterator being useful, I think that the
target vector code would be clearer if we just had the raw buffer. 
Layer the iterator on top of it, instead of re-implementing the
iterator in every target.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: unwind support for Linux 2.6 vsyscall DSO

[Andrew Cagney]

> So I can see either an iterator, or an update to to_query being added to 
>> the target vector.  Given that the iterator is a given, that might be 
>> the safest starting point - let the target maintainer go through and 
>> clean up to_query.
> 
> 
> While I won't argue about an iterator being useful, I think that the
> target vector code would be clearer if we just had the raw buffer. 
> Layer the iterator on top of it, instead of re-implementing the
> iterator in every target.

Each target won't implement the iterator.  Rather it will call on a 
generic unpack method, and have that it do it.

Andrew

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> - unpack an architecture's auxv
> - pack an architecture's auxv

This in fact differs with byte order and word size, not further by target.
So a generic utility function suffices for this.  If the responsibility for
packing and unpacking is in each target, they should all be able to use the
same utility function and stay about as simple as the block-reading target
code.  If the responsibility for unpacking lies with the caller of the
target function, then the single utility function suffices for all callers
(since then there is never a need for packing, only unpacking).

> target vector xfers via an iterator:
> - the low native code would be using the unpack method
> - the PIE and VSYSCALL code would be very simple
> - the CORE file code would need the pack method

You left out:

 - the pack method is required anywhere at all

> - the low remote could on-demand read the data

True.  FYI, the upper bound on real-world sizes of this data is 320 bytes.

> target vector xfers raw data:
> - the low native code would be simple
> - the PIE and VSYSCALL code would need to use the unpack method
> - the CORE file code would just write out the data

You left out:

 - no pack method need actually exist

> - the low remote code would, either be locked into transfering raw 
> bytes, or be forced to use the pack method

I can't see why it would want to do anything else, since the low-level
mechanisms available to the remote stub will be in terms of raw bytes.

> In my way earlier post, I also suggested "remote I/O' - a generic 
> mechanism for accessing arbitrary target data.  Looking through the 
> target vectore I see there is already "to_query()".  The original intent 
> of to_query was to handle exactly this sort of problem - pushing data 
> anonymously through the target vector.   The auxv fetch, with a large 
> bit of a struggle, could even be implemented using to_query.

to_query is adequate if its calling interface is refined to include
returning an error if the buffer is too small and the caller trying again
with a larger buffer (or returning an allocated buffer, whatever).  Aside
from the general hokeyness of the letter and string operation selectors,
the fixed size of the result buffer is the only thing really wrong with it.

> So?

So how come noone else seems to know to_query is there? :-)

> I've strong reservations towards adding redundant functionality to the 
> target vector.  However, I also note that the existing to_query method 
> isn't sufficient.

It's not too bad, i.e. right enough with a little fixing.  Moreover, it's
called in two places and implemented in two targets.  So changing it is not
going to be very hard.

> So I can see either an iterator, or an update to to_query being added to 
> the target vector.  Given that the iterator is a given, that might be 
> the safest starting point - let the target maintainer go through and 
> clean up to_query.

What's not a given is the iterator being the lowest level facility
available.  That makes the corefile writing code clunky.  I really don't
see the rationale for choosing an iterator as the target vector interface
for aux vector fetching.  With to_query or slight modifications of it,
block-fetching is the straightforward interface to layer on top of that;
that is also the most practical thing to use.  I have no objection to doing
that, and would be willing to adjust the very few other uses of to_query
for a cleaned-up interface (though I cannot test them).

Re: unwind support for Linux 2.6 vsyscall DSO

[Michael Snyder]

Roland McGrath wrote:

>>So?
> 
> 
> So how come noone else seems to know to_query is there? :-)

I knew.  Unfortunately, it's often proven inadequate, hence
there are separate queries for threads etc.

Maybe if to_query had been designed as an iterator in the first place...

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> I knew.  Unfortunately, it's often proven inadequate, hence
> there are separate queries for threads etc.
> 
> Maybe if to_query had been designed as an iterator in the first place...

Its interface is wholly vague, so a given query could encode any kind of
interface you want.  Iteration is easily expressed in such an interface
either just by specifying that's what a query means (different answer each
time) or by including a "next pointer" in queries and replies.

Re: unwind support for Linux 2.6 vsyscall DSO

[Andrew Cagney]

>> I knew.  Unfortunately, it's often proven inadequate, hence
>> there are separate queries for threads etc.
>> 
>> Maybe if to_query had been designed as an iterator in the first place...
> 
> 
> Its interface is wholly vague, so a given query could encode any kind of
> interface you want.  Iteration is easily expressed in such an interface
> either just by specifying that's what a query means (different answer each
> time) or by including a "next pointer" in queries and replies.

The interface was implemented based on the knowledge that had been 
accumulated upto that point in time.  More time passes, we learn some 
things, we forget others.

I'll draft something,
Andrew

Re: unwind support for Linux 2.6 vsyscall DSO

[Andrew Cagney]

>> - unpack an architecture's auxv
>> - pack an architecture's auxv
> 
> 
> This in fact differs with byte order and word size, not further by target.
> So a generic utility function suffices for this.  If the responsibility for
> packing and unpacking is in each target, they should all be able to use the
> same utility function and stay about as simple as the block-reading target
> code.  If the responsibility for unpacking lies with the caller of the
> target function, then the single utility function suffices for all callers
> (since then there is never a need for packing, only unpacking).

Unfortunatly, things aren't so simple :-(

Solaris:
#define AT_DCACHEBSIZE  10      /* smallest data cache block size */
#define AT_ICACHEBSIZE  11      /* smallest instruction cache block size */
#define AT_UCACHEBSIZE  12      /* smallest unified cache block size */
...

GNU/Linux:
#define AT_NOTELF 10    /* program is not ELF */
#define AT_UID    11    /* real uid */
#define AT_EUID   12    /* effective uid */
...

As with signals, the attribute indexes are per-os (and potentially per 
ISA).  So core code will need to define an OS independant set of enums 
and then map that onto the real numbers.

If I understand things correctly, the two driving needs are:

- being able to extract the value of AT_ENTRY, and AT_LINUX_<vsyscall 
address>

- being able to obtain the entire AUXV so that it can be saved in a core 
file

Would a per-os (technically per-architecture) SVR4 auxv lookup method 
that was implement using a fixed to_query() work?

Andrew

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> Unfortunatly, things aren't so simple :-(

Nothing in reality differs from what I've described.  I have already
mentioned the OS-specific nature of AT_* tag values.

> As with signals, the attribute indexes are per-os (and potentially per ISA).

Btw, these are tags, not indexes.  Referring to them as indexes might lead
people to write code that assumes things about the set of possible values.

> So core code will need to define an OS independant set of enums 
> and then map that onto the real numbers.

What for?  Examination of these values is OS-dependent.  I don't expect
that any OS-independent code will refer to any AT_* constants at all.

> If I understand things correctly, the two driving needs are:
> 
> - being able to extract the value of AT_ENTRY, and AT_LINUX_<vsyscall 
> address>

It's called AT_SYSINFO_EHDR.  As to AT_ENTRY, that is probably needed for
PIE support but that is so far just a guess on my part and AFAIK Elena has
not finished figuring out what is required.

> - being able to obtain the entire AUXV so that it can be saved in a core 
> file

Correct.

> Would a per-os (technically per-architecture) SVR4 auxv lookup method 
> that was implement using a fixed to_query() work?

I am not entirely clear on what you mean here.  Do you mean a to_query
encoding of the read_aux_vector functionality, wherein the query returns a
block of bytes?  That is what I have been suggesting.  As I have said
before, the "lookup" work of extracting the value for a given tag number
has no OS-specific or machine-specific components beyond knowing target
word size and byte order.  If that is what you mean by "lookup method",
then no, there is no need for a per-OS function to do that.  The choice of
what tag numbers you're looking for and what you'll do with the values is
OS-specific (as is the interest to look at all).

Re: unwind support for Linux 2.6 vsyscall DSO

[Elena Zannoni]

Roland McGrath writes:
 > > Unfortunatly, things aren't so simple :-(
 > 
 > Nothing in reality differs from what I've described.  I have already
 > mentioned the OS-specific nature of AT_* tag values.
 > 
 > > As with signals, the attribute indexes are per-os (and potentially per ISA).
 > 
 > Btw, these are tags, not indexes.  Referring to them as indexes might lead
 > people to write code that assumes things about the set of possible values.
 > 
 > > So core code will need to define an OS independant set of enums 
 > > and then map that onto the real numbers.
 > 
 > What for?  Examination of these values is OS-dependent.  I don't expect
 > that any OS-independent code will refer to any AT_* constants at all.
 > 
 > > If I understand things correctly, the two driving needs are:
 > > 
 > > - being able to extract the value of AT_ENTRY, and AT_LINUX_<vsyscall 
 > > address>
 > 
 > It's called AT_SYSINFO_EHDR.  As to AT_ENTRY, that is probably needed for
 > PIE support but that is so far just a guess on my part and AFAIK Elena has
 > not finished figuring out what is required.
 > 

If the AT_ENTRY value is correct for PIE, gdb will need it.  Gdb right
now assumes that the main executable is marked as EXEC to find the
entry point, and this doesn't hold for PIE.

 > > - being able to obtain the entire AUXV so that it can be saved in a core 
 > > file
 > 
 > Correct.
 > 
 > > Would a per-os (technically per-architecture) SVR4 auxv lookup method 
 > > that was implement using a fixed to_query() work?
 > 
 > I am not entirely clear on what you mean here.  Do you mean a to_query
 > encoding of the read_aux_vector functionality, wherein the query returns a
 > block of bytes?  That is what I have been suggesting.  As I have said

This is what I understood. So that it will work for remotes too.

 > before, the "lookup" work of extracting the value for a given tag number
 > has no OS-specific or machine-specific components beyond knowing target
 > word size and byte order.  If that is what you mean by "lookup method",

The target lookup method will invoke the to_query method (i.e. if
remote, it will use the remote protocol query feature). This target
lookup method will also know what tag to look for.

 > then no, there is no need for a per-OS function to do that.  The choice of

 > what tag numbers you're looking for and what you'll do with the values is
 > OS-specific (as is the interest to look at all).

You maybe are thinking that the tag is a parameter? If so the
return value will need to differ depending on what you are looking
for, and you will need a void* parameter (yuck!).

As I understood it, you will have a to_get_entry_point() and a
to_get_vsyscall_entry(), which then will query the target (via
to_query) for the auxv vector blocks and "parse" that.

elena

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> If the AT_ENTRY value is correct for PIE, gdb will need it.

Yes, it's correct in all cases.  You can be sure of this because it's the
only way the user entry point gets run by the dynamic linker, so if it were
wrong, the programs wouldn't run.

> You maybe are thinking that the tag is a parameter? If so the
> return value will need to differ depending on what you are looking
> for, and you will need a void* parameter (yuck!).

I don't know what you are talking about here.  bfd_vma is the only
appropriate type for all of the values in question.

> As I understood it, you will have a to_get_entry_point() and a
> to_get_vsyscall_entry(), which then will query the target (via
> to_query) for the auxv vector blocks and "parse" that.

I have never suggested to_get_vsyscall_entry and don't anticipate wanting
it.  I proposed to_read_aux_vector, and we have been discussing using
to_query to serve the same purpose with a different calling convention.
For the vsyscall purpose, I don't think any other target_ops addition is
useful or desireable.  The code to check for AT_SYSINFO_EHDR will be in the
linux-tdep function used for SOLIB_ADD or something like that (still being
hashed out, but that seems like the place for it).

to_get_entry_point seems like it might be a reasonable generic addition
since it's a generic issue that could apply to any kind of executable and
target in theory.  However, it might be desireable to frame it in terms of
a standard to_query request just so that remote.c and all the other target
code need not be touched, only the backends that can use the auxv fetching
and remote stubs that have a way to produce an answer.  There is the
contrary example of to_find_memory_regions, but that is notably wholly
unsupported by the remote protocol (i.e. no stub has the option of
implementing it even if it knows how).  The choice here is an issue for gdb
hackers, that I don't have any feelings about myself (just these observations).

Re: unwind support for Linux 2.6 vsyscall DSO

[Elena Zannoni]

Andrew Cagney writes:
 > >> - unpack an architecture's auxv
 > >> - pack an architecture's auxv
 > > 
 > > 
 > > This in fact differs with byte order and word size, not further by target.
 > > So a generic utility function suffices for this.  If the responsibility for
 > > packing and unpacking is in each target, they should all be able to use the
 > > same utility function and stay about as simple as the block-reading target
 > > code.  If the responsibility for unpacking lies with the caller of the
 > > target function, then the single utility function suffices for all callers
 > > (since then there is never a need for packing, only unpacking).
 > 
 > Unfortunatly, things aren't so simple :-(
 > 
 > Solaris:
 > #define AT_DCACHEBSIZE  10      /* smallest data cache block size */
 > #define AT_ICACHEBSIZE  11      /* smallest instruction cache block size */
 > #define AT_UCACHEBSIZE  12      /* smallest unified cache block size */
 > ...
 > 
 > GNU/Linux:
 > #define AT_NOTELF 10    /* program is not ELF */
 > #define AT_UID    11    /* real uid */
 > #define AT_EUID   12    /* effective uid */
 > ...
 > 
 > As with signals, the attribute indexes are per-os (and potentially per 
 > ISA).  So core code will need to define an OS independant set of enums 
 > and then map that onto the real numbers.
 > 
 > If I understand things correctly, the two driving needs are:
 > 
 > - being able to extract the value of AT_ENTRY, and AT_LINUX_<vsyscall 
 > address>
 > 

Yes, this will definitely help with pie. More in general, the mechanism
that gdb uses to calculate the entry point can be changed to use this
info.

 > - being able to obtain the entire AUXV so that it can be saved in a core 
 > file
 > 

Yes, the whole thing can be dumped as a new note.

 > Would a per-os (technically per-architecture) SVR4 auxv lookup method 
 > that was implement using a fixed to_query() work?

I think so, on Solaris some of the AT_* values in <sys/auxv.h> don't
match those in <elf.h> on linux and those in
gdb/../include/elf/elf.h. The AT_SYSINFO_EHDR seems to be 33 on all of
those, but other values are different. If we want to extend the auxv
handling to recognize more types, we may run into problems. 

elena



 > 
 > Andrew
 > 

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> I think so, on Solaris some of the AT_* values in <sys/auxv.h> don't
> match those in <elf.h> on linux and those in
> gdb/../include/elf/elf.h. The AT_SYSINFO_EHDR seems to be 33 on all of
> those, but other values are different. If we want to extend the auxv
> handling to recognize more types, we may run into problems. 

Perhaps you overlooked my explanation of all this on Monday:

  However, the AT_* values (except for AT_NULL==0) are neither standardized
  nor de facto reliably the same across operating systems (they are part of
  the SVR4 ABI spec for each processor I believe).  The values in
  include/elf/common.h are copied from glibc's <elf.h>, and are what GNU/Linux
  uses.  Some of the values used on Solaris conflict, though Sun seems to have
  taken to using AT_SUN_* names and values >=2000 for recent additions and so
  it now seems unlikely they will use values 32 or 33 and thus risk false
  matches with the Linux AT_SYSINFO_EHDR tag.  (FYI, NetBSD's elf.h header has
  all of Sun's values and no GNU/Linux values; however NetBSD itself uses only
  the tags <10 which in fact match exactly everywhere.)

Any use of auxv tags will always be OS-specific.  There is no universal
generic set to translate them to or anything like that.  The fact that
there is an aux vector in a given format with tags and values is common
code worth sharing across platforms, but that is all.

Re: unwind support for Linux 2.6 vsyscall DSO

[Daniel Jacobowitz]

On Wed, Oct 08, 2003 at 05:00:36PM -0400, Andrew Cagney wrote:
> >>- unpack an architecture's auxv
> >>- pack an architecture's auxv
> >
> >
> >This in fact differs with byte order and word size, not further by target.
> >So a generic utility function suffices for this.  If the responsibility for
> >packing and unpacking is in each target, they should all be able to use the
> >same utility function and stay about as simple as the block-reading target
> >code.  If the responsibility for unpacking lies with the caller of the
> >target function, then the single utility function suffices for all callers
> >(since then there is never a need for packing, only unpacking).
> 
> Unfortunatly, things aren't so simple :-(
> 
> Solaris:
> #define AT_DCACHEBSIZE  10      /* smallest data cache block size */
> #define AT_ICACHEBSIZE  11      /* smallest instruction cache block size */
> #define AT_UCACHEBSIZE  12      /* smallest unified cache block size */
> ...
> 
> GNU/Linux:
> #define AT_NOTELF 10    /* program is not ELF */
> #define AT_UID    11    /* real uid */
> #define AT_EUID   12    /* effective uid */
> ...
> 
> As with signals, the attribute indexes are per-os (and potentially per 
> ISA).  So core code will need to define an OS independant set of enums 
> and then map that onto the real numbers.
> 
> If I understand things correctly, the two driving needs are:
> 
> - being able to extract the value of AT_ENTRY, and AT_LINUX_<vsyscall 
> address>
> 
> - being able to obtain the entire AUXV so that it can be saved in a core 
> file
> 
> Would a per-os (technically per-architecture) SVR4 auxv lookup method 
> that was implement using a fixed to_query() work?

Sounds more or less good to me.  I don't think we need a generic
gdbarch method for querying auxv; more something like a
gdbarch_auxv_entry_point () and a gdbarch_auxv_sysinfo_dso_address ()?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: unwind support for Linux 2.6 vsyscall DSO

[Daniel Jacobowitz]

On Mon, Oct 06, 2003 at 04:59:52PM -0700, Roland McGrath wrote:
> > There should be an iterator over the entries in the /proc/pid/auxv
> > file with a callback that processes each entry. So that the iterator
> > could be used not just for finding the AT_SYSINFO_EHDR entry. 
> 
> Ok, an iterator interface is fine with me, just marginally less efficient
> than the searcher when only one tag is actually used (and more efficient if
> many tags are used).  (I had not proposed any function that would be useful
> solely for AT_SYSINFO_EHDR, though that was one of Jim's early
> suggestions.)  If others agree this is the right interface for a target_ops
> addition, I will write that patch.
> 
> > I think the number of iterations would be your size_t above divided by
> > the size of an auxv_t or something similar.
> 
> Indeed.
> 
> > The first thing that happens is that the breakpoint inserted at the
> > dynamic linker is hit, at which point gdb gets to add the shlibs.
> 
> Obviously that's not the first thing, since inserting the breakpoint in the
> dynamic linker happens before that.  It's ideal to do the vsyscall DSO
> setup before letting the dynamic linker run at all.  That way you have that
> information in case you get a signal in the early part of dynamic linker
> startup, or attach to a process that is for some reason blocked in a system
> call in that early stage, and want to see a backtrace to understand the
> state.

I agree that this would be nice.  This'll require a new hook. 
Preferably it should be done using the new observers mechanism.

> > enable_break: search for .interp in /scratch/ezannoni/pie-work/native/gdb/testsuite/gdb.base/break
> > enable_break: opening /lib/ld-linux.so.2
> > elf_locate_base: DT_DEBUG entry has value 0x0
> > svr4_current_sos: no DT_DEBUG found
> 
> I don't see your debugging code in mainline gdb and so I can only guess
> what these messages mean in terms of the code. 
> 
> Are you sure this doesn't mean it looked at the sh process before it
> exec'd?  It wouldn't find anything there because it would be looking for
> DT_DEBUG from the .dynamic address of the "break" binary and sh's layout is
> different (so it's reading arbitrary other data and not finding the tag).
> 
> > Since we need the iterator method, this read/parse becomes a very
> > small piece and fits nicely in linux-proc.c in the live inferior
> > case. For the corefile/remote case, you would ask bfd for the .auxv
> > section of the core file and parse that in order to get an element of
> > the vector and this is also something that can be in gdb, unless you
> > want to reuse that in some other tool.
> 
> We are all clear on the steps that need to be performed.  The part that
> parses the format and deals with the target wordsize question and
> byteswapping, is common work between the live and core cases that might use
> a shared function rather than duplicative source code.  That is what we
> have been discussing.
> 
> You said "corefile/remote case", but looking for a .auxv section applies
> only to core files.  I don't think we have discussed the remote case.  It
> would require the remote stub reading the local /proc/PID/auxv file and
> giving the information back to gdb.  I'm not aware of anything in the
> remote protocol to allow that.

No, but extending it to do so is easy (and vital).  I'll do it later.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: unwind support for Linux 2.6 vsyscall DSO

[Michael Snyder]

Roland McGrath wrote:

> You said "corefile/remote case", but looking for a .auxv section applies
> only to core files.  I don't think we have discussed the remote case.  It
> would require the remote stub reading the local /proc/PID/auxv file and
> giving the information back to gdb.  I'm not aware of anything in the
> remote protocol to allow that.

Something similar would be required in order to do a remote gcore --
which we would like to do someday.

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> Something similar would be required in order to do a remote gcore --
> which we would like to do someday.

It seems like to_query could be the way to go here.  It's already
transferred by the remote protocol.  Perhaps both read_aux_vector and
find_memory_regions should be recast as to_query queries; once the
suffering is done once, it makes it easy to support them in gdbserver.

Re: unwind support for Linux 2.6 vsyscall DSO

[Jim Blandy]

Roland McGrath <roland@redhat.com> writes:
> > I think you can rely on SOLIB_ADD not being called too early.  It would
> > be a bug if we ever called it before the shell execs the executable under
> > debug, because we use the VMA of the .dynamic section of the executable
> > file to find the dynamic structure in the inferior's memory anyway.  We
> > couldn't even find the shell's shared library list.
> 
> Right, it would fail to find any list at all.  If it treats that as "empty
> list" then this won't be a change from before and so it's a harmless no-op.
> Are we sure that is not what is happening now?  If it is, it's harmless now
> but having the auxv-reading done too early would not be harmless.

Well, child_create_inferior calls fork_inferior, passing ptrace_him as
the init_trace_fun.  ptrace_him calls startup_inferior to get past the
shell.  startup_inferior uses 'resume' to get past the various traps
that occur before we reach the actual program under debug; resume,
unlike proceed (gotta love it) does not insert breakpoints, and thus
will never yield BPSTAT_WHAT_CHECK_SHLIBS, and thus will never call
SOLIB_ADD.  I verified this by actually starting up a program and
watching things happen.

So, yes, we're sure.  Happy?  :)

(To be honest, I'm never sure of much when dealing with the program
startup and event analysis code...)

> > I disagree with moving the read of auxv to bfd. Gdb already processes
> > plenty of /proc files (on Solaris using 2 interfaces), and has target
> > methods defined for these, so I would treat the auxv case just like the
> > others.
> 
> What we have been discussing most recently is only a BFD utility function
> to examine raw auxv blocks that have already been read in somehow.
> i.e., a trivial helper function that these target methods would use.
> It doesn't matter to me whether this is in bfd/elf.c or gdb/elfread.c.

I can see going either way.  The code in question just does a bit of
grunging with ElfNN_External_Auxv and ElfNN_Internal_Auxv, but has no
contact with other GDB stuff, so I figured it should go in BFD.  The
involvement of /proc wasn't really at issue --- when you're processing
cores, it isn't involved at all.

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> So, yes, we're sure.  Happy?  :)

Ok, good.  Are people then agreed that adding a Linux-specific SOLIB_ADD
that does this stuff in addition to calling solib_add is the way to go?


Thanks,
Roland

Re: unwind support for Linux 2.6 vsyscall DSO

[Kevin Buettner]

On Oct 6,  9:45pm, Roland McGrath wrote:

> Ok, good.  Are people then agreed that adding a Linux-specific SOLIB_ADD
> that does this stuff in addition to calling solib_add is the way to go?

I do not want to see a linux-specific SOLIB_ADD added to gdb.  I'm
(still) trying to collapse all of the various SOLIB_ADD's down to just
one function.  Progress has been slow, but it's being made.

Adding a call to a new gdbarch method in solib_add() (in solib.c)
might be acceptable.  This method could be set up in the
{$arch}-linux-tdep.c files.

However, before going this route (adding a new gdbarch method), I'd
prefer that you look at TARGET_SO_SPECIAL_SYMBOL_HANDLING() to see if
it could be used to serve your purposes.  If it can't, then you should
consider adding a new TARGET_SO_... method which is called from
solib_add().  In either case, the hook for setting up a call to some
linux-specific code from solib-svr4.c could be done in a manner
similar that used to set the link map offsets fetcher.  See
set_solib_svr4_fetch_link_map_offsets() in solib-svr4.[hc].

To recap, here are my preferences (from most to least preferable):

 - See if TARGET_SO_SPECIAL_SYMBOL_HANDLING can be made to work.  (It's
   already called by solib_add.)
 - Add a new TARGET_SO_... method which is called from solib_add().
 - Add a new gdbarch method which is called from solib_add().

Kevin

Re: unwind support for Linux 2.6 vsyscall DSO

[Daniel Jacobowitz]

On Thu, Oct 09, 2003 at 12:58:05PM -0700, Kevin Buettner wrote:
> On Oct 6,  9:45pm, Roland McGrath wrote:
> 
> > Ok, good.  Are people then agreed that adding a Linux-specific SOLIB_ADD
> > that does this stuff in addition to calling solib_add is the way to go?
> 
> I do not want to see a linux-specific SOLIB_ADD added to gdb.  I'm
> (still) trying to collapse all of the various SOLIB_ADD's down to just
> one function.  Progress has been slow, but it's being made.
> 
> Adding a call to a new gdbarch method in solib_add() (in solib.c)
> might be acceptable.  This method could be set up in the
> {$arch}-linux-tdep.c files.
> 
> However, before going this route (adding a new gdbarch method), I'd
> prefer that you look at TARGET_SO_SPECIAL_SYMBOL_HANDLING() to see if
> it could be used to serve your purposes.  If it can't, then you should
> consider adding a new TARGET_SO_... method which is called from
> solib_add().  In either case, the hook for setting up a call to some
> linux-specific code from solib-svr4.c could be done in a manner
> similar that used to set the link map offsets fetcher.  See
> set_solib_svr4_fetch_link_map_offsets() in solib-svr4.[hc].
> 
> To recap, here are my preferences (from most to least preferable):
> 
>  - See if TARGET_SO_SPECIAL_SYMBOL_HANDLING can be made to work.  (It's
>    already called by solib_add.)
>  - Add a new TARGET_SO_... method which is called from solib_add().
>  - Add a new gdbarch method which is called from solib_add().

The problem with using SOLIB_ADD for this is that we can't SOLIB_ADD
safely till we hit the dynamic linker breakpoint, but it would be
_really_ nice to be able to load this object right after the inferior
starts (and for static binaries, etc etc).  How would you suggets we do
that?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: unwind support for Linux 2.6 vsyscall DSO

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> The problem with using SOLIB_ADD for this is that we can't SOLIB_ADD
> safely till we hit the dynamic linker breakpoint, but it would be
> _really_ nice to be able to load this object right after the inferior
> starts (and for static binaries, etc etc).  How would you suggets we do
> that?

Well, look, the whole association with SOLIB_ADD at all was just based
on the intuition that "Hey, this vsyscall thing is like a shared
library!"  Nothing more profound than that.  So if it turns out that
sticking with SOLIB_ADD makes things complicated, then it'd be much
better to just add calls to the core, attach, and run code, or
whereever else is appropriate, that does things exactly the way you
want.

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> Daniel Jacobowitz <drow@mvista.com> writes:
> > The problem with using SOLIB_ADD for this is that we can't SOLIB_ADD
> > safely till we hit the dynamic linker breakpoint, but it would be
> > _really_ nice to be able to load this object right after the inferior
> > starts (and for static binaries, etc etc).  How would you suggets we do
> > that?
> 
> Well, look, the whole association with SOLIB_ADD at all was just based
> on the intuition that "Hey, this vsyscall thing is like a shared
> library!"  Nothing more profound than that.  So if it turns out that
> sticking with SOLIB_ADD makes things complicated, then it'd be much
> better to just add calls to the core, attach, and run code, or
> whereever else is appropriate, that does things exactly the way you
> want.

In the prior discussion I got the impression that SOLIB_ADD did happen
early enough (right after the exec stop), and just got repeated more times
later when there is actually anything in the dynamic linker's list.  Is
that not accurate?

Kevin says:
> I think that's what TARGET_CREATE_INFERIOR_HOOK is for.

This is only called in the "run" case.  There is also
SOLIB_CREATE_INFERIOR_HOOK, but that is called only in the "run", "target
remote", and follow-exec cases AFAICT.  

To reiterate, we need something that is called at the break-on-exec from
run, immediately after attach, immediately after loading a core file, and
after follow-exec breaks if that support is real.

We also need to clear out the state that hook will set up.  clear_solib
seems to be called at a reasonable time on the next "run", though only
SOLIB_RESTART is called in the follow-exec case and I'm not sure if
anything helpful is called to reset state before a new "attach".

The hooks I need are "we've just seen a new address space for the first
time" and "scratch that, the address space is gone".  I suppose actually
just the one suffices if it's never called extra times, so it just clears
the old and fetches the new every time.


Thanks,
Roland

Re: unwind support for Linux 2.6 vsyscall DSO

[Kevin Buettner]

On Oct 9,  3:20pm, Roland McGrath wrote:

> Kevin says:
> > I think that's what TARGET_CREATE_INFERIOR_HOOK is for.
> 
> This is only called in the "run" case.  There is also
> SOLIB_CREATE_INFERIOR_HOOK, but that is called only in the "run", "target
> remote", and follow-exec cases AFAICT.  
> 
> To reiterate, we need something that is called at the break-on-exec from
> run, immediately after attach, immediately after loading a core file, and
> after follow-exec breaks if that support is real.

It may be possible that the existing mechanisms (either
TARGET_CREATE_INFERIOR_HOOK or SOLIB_CREATE_INFERIOR_HOOK) are
adequate, but simply not called from enough places.  If these
must stay as they are, then we need some new hooks.  These days,
we normally set these up as gdbarch methods.  For linux, such a
method could be registered in the $arch-linux-tdep.c file.

> We also need to clear out the state that hook will set up.  clear_solib
> seems to be called at a reasonable time on the next "run", though only
> SOLIB_RESTART is called in the follow-exec case and I'm not sure if
> anything helpful is called to reset state before a new "attach".
> 
> The hooks I need are "we've just seen a new address space for the first
> time" and "scratch that, the address space is gone".  I suppose actually
> just the one suffices if it's never called extra times, so it just clears
> the old and fetches the new every time.

I think I had better go back and read past discussion.

Kevin

Re: unwind support for Linux 2.6 vsyscall DSO

[Michael Snyder]

Kevin Buettner wrote:
> On Oct 9,  3:20pm, Roland McGrath wrote:
> 
> 
>>Kevin says:
>>
>>>I think that's what TARGET_CREATE_INFERIOR_HOOK is for.
>>
>>This is only called in the "run" case.  There is also
>>SOLIB_CREATE_INFERIOR_HOOK, but that is called only in the "run", "target
>>remote", and follow-exec cases AFAICT.  
>>
>>To reiterate, we need something that is called at the break-on-exec from
>>run, immediately after attach, immediately after loading a core file, and
>>after follow-exec breaks if that support is real.
> 
> 
> It may be possible that the existing mechanisms (either
> TARGET_CREATE_INFERIOR_HOOK or SOLIB_CREATE_INFERIOR_HOOK) are
> adequate, but simply not called from enough places.  If these
> must stay as they are, then we need some new hooks.  These days,
> we normally set these up as gdbarch methods.  For linux, such a
> method could be registered in the $arch-linux-tdep.c file.

History-man says, TARGET_CREATE_INFERIOR_HOOK was added in 1995,
specifically to fork-child.c, to allow somebody to get control
of the new child process just before execution of the first
instruction.  Seems like we would need a different hook for,
say, attach.

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> It may be possible that the existing mechanisms (either
> TARGET_CREATE_INFERIOR_HOOK or SOLIB_CREATE_INFERIOR_HOOK) are
> adequate, but simply not called from enough places.  If these
> must stay as they are, then we need some new hooks.

I have nothing to add on the subject of whether certain existing hooks
could be called from more places.  I'll leave that to you folks.  It's
certainly the case that a hook of any name, old or new, is adequate if it's
called from the right places.

> These days, we normally set these up as gdbarch methods.  For linux, such
> a method could be registered in the $arch-linux-tdep.c file.

Ok.  I think I understand how to do that if it's the right way to go.
At the moment, I have working code by tweaking the SOLIB macro in tm-linux.h.
Until you all decide whether some existing hook should be called from
elsewhere or a new one added to all those places, I won't bother writing
code for either alternative.


Thanks,
Roland

Re: unwind support for Linux 2.6 vsyscall DSO

[Kevin Buettner]

On Oct 9,  3:20pm, Roland McGrath wrote:

> > Daniel Jacobowitz <drow@mvista.com> writes:
> > > The problem with using SOLIB_ADD for this is that we can't SOLIB_ADD
> > > safely till we hit the dynamic linker breakpoint, but it would be
> > > _really_ nice to be able to load this object right after the inferior
> > > starts (and for static binaries, etc etc).  How would you suggets we do
> > > that?
> > 
> > Well, look, the whole association with SOLIB_ADD at all was just based
> > on the intuition that "Hey, this vsyscall thing is like a shared
> > library!"  Nothing more profound than that.  So if it turns out that
> > sticking with SOLIB_ADD makes things complicated, then it'd be much
> > better to just add calls to the core, attach, and run code, or
> > whereever else is appropriate, that does things exactly the way you
> > want.
> 
> In the prior discussion I got the impression that SOLIB_ADD did happen
> early enough (right after the exec stop), and just got repeated more times
> later when there is actually anything in the dynamic linker's list.  Is
> that not accurate?

SOLIB_ADD will only be called when the dynamic linker's "hey, I've
just (un)loaded something new" breakpoint has been hit.  (More
precisely, this is the breakpoint placed at r_brk in the r_debug
struct.) This occurs quite early in the execution of the program, but
it might not be early enough.  Also, as Daniel alludes, it won't
happen at all for static binaries.

Kevin

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> SOLIB_ADD will only be called when the dynamic linker's "hey, I've
> just (un)loaded something new" breakpoint has been hit.  (More
> precisely, this is the breakpoint placed at r_brk in the r_debug
> struct.) This occurs quite early in the execution of the program, but
> it might not be early enough.  Also, as Daniel alludes, it won't
> happen at all for static binaries.

Ok, then that is really not sufficient.  I apparently got a mistaken
impression of how early it gets called from the previous discussion.  The
more I think about it, the more a single new hook that is clearly "inferior
address space we haven't seen before" (i.e. exec/attach but not fork) looks
like the clean and sensible thing.  All the existing hooks have semantics
that are either not quite clear or are clearly different from that.

Re: unwind support for Linux 2.6 vsyscall DSO

[Kevin Buettner]

On Oct 10,  6:47pm, Roland McGrath wrote:

> > SOLIB_ADD will only be called when the dynamic linker's "hey, I've
> > just (un)loaded something new" breakpoint has been hit.  (More
> > precisely, this is the breakpoint placed at r_brk in the r_debug
> > struct.) This occurs quite early in the execution of the program, but
> > it might not be early enough.  Also, as Daniel alludes, it won't
> > happen at all for static binaries.
> 
> Ok, then that is really not sufficient.  I apparently got a mistaken
> impression of how early it gets called from the previous discussion.  The
> more I think about it, the more a single new hook that is clearly "inferior
> address space we haven't seen before" (i.e. exec/attach but not fork) looks
> like the clean and sensible thing.  All the existing hooks have semantics
> that are either not quite clear or are clearly different from that.

Sounds right to me...

Kevin

Re: unwind support for Linux 2.6 vsyscall DSO

[Kevin Buettner]

On Oct 9,  4:02pm, Daniel Jacobowitz wrote:

> The problem with using SOLIB_ADD for this is that we can't SOLIB_ADD
> safely till we hit the dynamic linker breakpoint, but it would be
> _really_ nice to be able to load this object right after the inferior
> starts (and for static binaries, etc etc).  How would you suggets we do
> that?

I think that's what TARGET_CREATE_INFERIOR_HOOK is for.

Kevin

Re: unwind support for Linux 2.6 vsyscall DSO

[Daniel Jacobowitz]

On Thu, Oct 09, 2003 at 01:21:02PM -0700, Kevin Buettner wrote:
> On Oct 9,  4:02pm, Daniel Jacobowitz wrote:
> 
> > The problem with using SOLIB_ADD for this is that we can't SOLIB_ADD
> > safely till we hit the dynamic linker breakpoint, but it would be
> > _really_ nice to be able to load this object right after the inferior
> > starts (and for static binaries, etc etc).  How would you suggets we do
> > that?
> 
> I think that's what TARGET_CREATE_INFERIOR_HOOK is for.

Sounds good to me.

By the way, assuming I remember this correctly, the DSO will _also_
show up in the link map we get from the dynamic loader.  Not sure how
that will influence things.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: unwind support for Linux 2.6 vsyscall DSO

[Kevin Buettner]

On Oct 9,  4:23pm, Daniel Jacobowitz wrote:

> On Thu, Oct 09, 2003 at 01:21:02PM -0700, Kevin Buettner wrote:
> > On Oct 9,  4:02pm, Daniel Jacobowitz wrote:
> > 
> > > The problem with using SOLIB_ADD for this is that we can't SOLIB_ADD
> > > safely till we hit the dynamic linker breakpoint, but it would be
> > > _really_ nice to be able to load this object right after the inferior
> > > starts (and for static binaries, etc etc).  How would you suggets we do
> > > that?
> > 
> > I think that's what TARGET_CREATE_INFERIOR_HOOK is for.
> 
> Sounds good to me.
> 
> By the way, assuming I remember this correctly, the DSO will _also_
> show up in the link map we get from the dynamic loader.  Not sure how
> that will influence things.

If this entry is already present in the list of so_list structs (pointed
at by ``so_list_head''), it shouldn't cause any problem.  If it's not,
an attempt will be made to load it.  I'm not sure what the result of
that will be.

Kevin

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> On Oct 9,  4:23pm, Daniel Jacobowitz wrote:
> > By the way, assuming I remember this correctly, the DSO will _also_
> > show up in the link map we get from the dynamic loader.  Not sure how
> > that will influence things.
> 
> If this entry is already present in the list of so_list structs (pointed
> at by ``so_list_head''), it shouldn't cause any problem.  If it's not,
> an attempt will be made to load it.  I'm not sure what the result of
> that will be.

It will appear in the dynamic linker's list of objects, but will not have a
file name.  (Actually, a bogus patch from Dan went into glibc that makes it
report its soname as file name, but I'm fixing that.)  The file name in
l_name will be an empty string.  (With the broken glibc of the moment, it
reports "linux-gate.so.1", a file that exists nowhere and never will.)
There is no way for you to associate this record with the implicit DSO.
All the information you have is the (empty) name and an l_addr of zero
(because the kernel-supplied DSO is effectively "prelinked" to its address).
So, I think that will not actually interfere since it will appear to be
some bogon.

Re: unwind support for Linux 2.6 vsyscall DSO

[Kevin Buettner]

On Oct 9,  3:32pm, Roland McGrath wrote:

> It will appear in the dynamic linker's list of objects, but will not have a
> file name.  (Actually, a bogus patch from Dan went into glibc that makes it
> report its soname as file name, but I'm fixing that.)  The file name in
> l_name will be an empty string.  (With the broken glibc of the moment, it
> reports "linux-gate.so.1", a file that exists nowhere and never will.)

Is there any reason there couldn't be a /proc/PID entry for this file?

(My apologies if this has already been discussed ad nauseum.  I
haven't really been paying attention up 'til now.)

> There is no way for you to associate this record with the implicit DSO.
> All the information you have is the (empty) name and an l_addr of zero
> (because the kernel-supplied DSO is effectively "prelinked" to its address).
> So, I think that will not actually interfere since it will appear to be
> some bogon.

Okay.

Kevin

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> Is there any reason there couldn't be a /proc/PID entry for this file?

There could be one, but there isn't one and I can't see a whole lot of
reason to have one.  That's a lot less general and remote-friendly.

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

> I do not want to see a linux-specific SOLIB_ADD added to gdb.  I'm
> (still) trying to collapse all of the various SOLIB_ADD's down to just
> one function.  Progress has been slow, but it's being made.

Ok, glad to hear it.  The mess there now was less than inspiring.  It's
pretty damn confusing figuring out when CLEAR_SOLIB gets called for one
thing (and when clear_solib does but not CLEAR_SOLIB!).

> However, before going this route (adding a new gdbarch method), I'd
> prefer that you look at TARGET_SO_SPECIAL_SYMBOL_HANDLING() to see if it
> could be used to serve your purposes.  If it can't, then you should
> consider adding a new TARGET_SO_... method which is called from
> solib_add().  

None of those hooks is in quite the right place, so we'll need a new one.

> In either case, the hook for setting up a call to some linux-specific
> code from solib-svr4.c could be done in a manner similar that used to set
> the link map offsets fetcher.  See
> set_solib_svr4_fetch_link_map_offsets() in solib-svr4.[hc].

Is this in the context of a new TARGET_SO_* hook or without it?  The
fetch_link_map_offsets thing is some special magic internal to solib-svr4.c
and not matched with a target_so_ops hook.  Are you talking about
replicating that?  A new target_so_ops hook is needed to get called in the
right places.  That being the case, are you suggesting a
set_solib_svr4_new_hook_name that changes svr4_so_ops.new_hook_name?
Or what exactly?  We also need to do something at clear_solib time.
There is a target_so_ops hook for that already, but we need to call the old
svr4_clear_solib as well as do the new linux-specific work.

>  - See if TARGET_SO_SPECIAL_SYMBOL_HANDLING can be made to work.  (It's
>    already called by solib_add.)

It's only called if other symbols were loaded.  So at startup it won't be
called, and if `set auto-solib-add 0' has been done it won't ever be called.

>  - Add a new TARGET_SO_... method which is called from solib_add().

Unless solib_add is changed to call TARGET_SO_SPECIAL_SYMBOL_HANDLING
unconditionally, we need something new.  

>  - Add a new gdbarch method which is called from solib_add().

There are so many different function tables in gdb, I haven't the foggiest
idea how this meaningfully differs from target_so_ops additions.  I
certainly don't know any reasons to prefer the gdbarch flavor if you find
it less preferable.

Re: unwind support for Linux 2.6 vsyscall DSO

[Kevin Buettner]

On Oct 9,  3:07pm, Roland McGrath wrote:

> > In either case, the hook for setting up a call to some linux-specific
> > code from solib-svr4.c could be done in a manner similar that used to set
> > the link map offsets fetcher.  See
> > set_solib_svr4_fetch_link_map_offsets() in solib-svr4.[hc].
> 
> Is this in the context of a new TARGET_SO_* hook or without it?  The
> fetch_link_map_offsets thing is some special magic internal to solib-svr4.c
> and not matched with a target_so_ops hook.  Are you talking about
> replicating that?  A new target_so_ops hook is needed to get called in the
> right places.  That being the case, are you suggesting a
> set_solib_svr4_new_hook_name that changes svr4_so_ops.new_hook_name?
> Or what exactly?  We also need to do something at clear_solib time.
> There is a target_so_ops hook for that already, but we need to call the old
> svr4_clear_solib as well as do the new linux-specific work.

I was suggesting a hook or hooks, (using a mechanisms similar to
set_solib_svr4_fetch_link_map_offsets() for setting up the hook)
to be used either with existing or new TARGET_SO_* methods.

It sounds like this won't be sufficient for your purposes though.

I see you've sent some other mail on this matter.  I'll reply further
there.

Kevin

Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath]

Here is an alternate version of my patch, omitting the Solaris parts.  This
uses an iterator interface as you requested.  I didn't add a utility
function but duplicated the code that might be in one.  This also works
(writes a good NT_AUXV note), but the core file writing additions are now
rather clunky, and that code has to be duplicated for Solaris (or factored
out).  I prefer the first version.


Thanks,
Roland


Index: target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.55
diff -b -p -u -r1.55 target.c
--- target.c	2 Oct 2003 20:28:30 -0000	1.55
+++ target.c	7 Oct 2003 03:29:27 -0000
@@ -624,6 +624,7 @@ update_current_target (void)
       INHERIT (to_async, t);
       INHERIT (to_async_mask_value, t);
       INHERIT (to_find_memory_regions, t);
+      INHERIT (to_read_aux_vector, t);
       INHERIT (to_make_corefile_notes, t);
       INHERIT (to_get_thread_local_address, t);
       INHERIT (to_magic, t);
@@ -1500,6 +1501,13 @@ static int dummy_find_memory_regions (in
   return 0;
 }
 
+/* Error-catcher for target_read_aux_vector */
+static int dummy_read_aux_vector (int (*ignore1) (), void *ignore2)
+{
+  error ("No target.");
+  return 0;
+}
+
 /* Error-catcher for target_make_corefile_notes */
 static char * dummy_make_corefile_notes (bfd *ignore1, int *ignore2)
 {
@@ -1521,6 +1529,7 @@ init_dummy_target (void)
   dummy_target.to_pid_to_str = normal_pid_to_str;
   dummy_target.to_stratum = dummy_stratum;
   dummy_target.to_find_memory_regions = dummy_find_memory_regions;
+  dummy_target.to_read_aux_vector = dummy_read_aux_vector;
   dummy_target.to_make_corefile_notes = dummy_make_corefile_notes;
   dummy_target.to_magic = OPS_MAGIC;
 }
Index: target.h
===================================================================
RCS file: /cvs/src/src/gdb/target.h,v
retrieving revision 1.41
diff -b -p -u -r1.41 target.h
--- target.h	17 Jun 2003 20:28:13 -0000	1.41
+++ target.h	7 Oct 2003 03:29:27 -0000
@@ -322,6 +322,7 @@ struct target_ops
 					    int, int, int, 
 					    void *), 
 				   void *);
+    int (*to_read_aux_vector) (int (*) (const void *, void *), void *);
     char * (*to_make_corefile_notes) (bfd *, int *);
 
     /* Return the thread-local address at OFFSET in the
@@ -939,6 +940,14 @@ extern void (*target_new_objfile_hook) (
      (current_target.to_find_memory_regions) (FUNC, DATA)
 
 /*
+ * Function to read target startup auxilliary vector (ELF-specific).
+ * Returns a malloc'd buffer of ELF auxv data, and sets *LENP to its size.
+ */
+
+#define target_read_aux_vector(FUNC, DATA) \
+     (current_target.to_read_aux_vector) (FUNC, DATA)
+
+/*
  * Compose corefile .note section.
  */
 
Index: inftarg.c
===================================================================
RCS file: /cvs/src/src/gdb/inftarg.c,v
retrieving revision 1.18
diff -b -p -u -r1.18 inftarg.c
--- inftarg.c	21 Sep 2003 01:26:45 -0000	1.18
+++ inftarg.c	7 Oct 2003 03:29:27 -0000
@@ -628,6 +628,14 @@ inftarg_set_find_memory_regions (int (*f
   child_ops.to_find_memory_regions = func;
 }
 
+/* Take over the 'read_aux_vector' vector from inftarg.c. */
+void
+inftarg_set_read_aux_vector (int (*func) (int (*) (const void *, void *),
+					  void *))
+{
+  child_ops.to_read_aux_vector = func;
+}
+
 /* Take over the 'make_corefile_notes' vector from inftarg.c. */
 extern void 
 inftarg_set_make_corefile_notes (char * (*func) (bfd *, int *))
Index: linux-proc.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-proc.c,v
retrieving revision 1.20
diff -b -p -u -r1.20 linux-proc.c
--- linux-proc.c	1 Oct 2003 20:36:56 -0000	1.20
+++ linux-proc.c	7 Oct 2003 03:29:27 -0000
@@ -161,6 +161,72 @@ linux_find_memory_regions (int (*func) (
   return 0;
 }
 
+static int
+procfs_read_aux_vector (int (*func) (const Elf_Internal_Auxv *, void *),
+			void *data)
+{
+  char pathname[MAXPATHLEN];
+  union
+  {
+    Elf32_External_Auxv av32[20];
+    Elf64_External_Auxv av64[10];
+  } buf;
+  int fd, n, ret;
+
+  sprintf (pathname, "/proc/%d/auxv", PIDGET (inferior_ptid));
+  fd = open (pathname, O_RDONLY);
+  if (fd < 0)
+    return 0;			/* XXX Call error here? */
+
+  ret = 0;
+  while (1)
+    {
+      n = read (fd, &buf, sizeof buf);
+      if (n <= 0)		/* Hit EOF or read error.  */
+	return 0;
+
+      switch (bfd_arch_bits_per_address (exec_bfd))
+	{
+	default:
+	  break;
+
+	case 32:
+	  {
+	    const Elf32_External_Auxv *av;
+	    for (av = buf.av32; (char *) av < (char *) &buf + n; ++av)
+	      {
+		Elf_Internal_Auxv elt;
+		elt.a_type = bfd_get_32 (exec_bfd, av->a_type);
+		elt.a_val = bfd_get_32 (exec_bfd, av->a_val);
+		ret = (*func) (&elt, data);
+		if (ret != 0)
+		  break;
+	      }
+	    continue;
+	  }
+	case 64:
+	  {
+	    const Elf64_External_Auxv *av;
+	    for (av = buf.av64; (char *) av < (char *) &buf + n; ++av)
+	      {
+		Elf_Internal_Auxv elt;
+		elt.a_type = bfd_get_64 (exec_bfd, av->a_type);
+		elt.a_val = bfd_get_64 (exec_bfd, av->a_val);
+		ret = (*func) (&elt, data);
+		if (ret != 0)
+		  break;
+	      }
+	    continue;
+	  }
+	}
+
+      break;
+    }
+
+  close (fd);
+  return ret;
+}
+
 /* Function: linux_do_thread_registers
  *
  * Records the thread's register state for the corefile note section.
@@ -255,6 +321,46 @@ linux_do_registers (bfd *obfd, ptid_t pt
   return note_data;
 }
 
+static int
+linux_auxv_count (const void *av, void *data)
+{
+  ++*(int *) data;
+  return 0;
+}
+
+static int
+linux_auxv_reconstruct (const void *internal, void *data)
+{
+  const Elf_Internal_Auxv *av = internal;
+  bfd_byte **ptr = data;
+
+  switch (bfd_arch_bits_per_address (exec_bfd))
+    {
+    default:
+      break;
+
+    case 32:
+      {
+	bfd_put_32 (exec_bfd, av->a_type, *ptr);
+	*ptr += 4;
+	bfd_put_32 (exec_bfd, av->a_val, *ptr);
+	*ptr += 4;
+	break;
+      }
+
+    case 64:
+      {
+	bfd_put_64 (exec_bfd, av->a_type, *ptr);
+	*ptr += 8;
+	bfd_put_64 (exec_bfd, av->a_val, *ptr);
+	*ptr += 8;
+	break;
+      }
+    }
+
+  return 0;
+}
+
 /* Function: linux_make_note_section
  *
  * Fills the "to_make_corefile_note" target vector.
@@ -271,6 +377,7 @@ linux_make_note_section (bfd *obfd, int 
   char psargs[80] = { '\0' };
   char *note_data = NULL;
   ptid_t current_ptid = inferior_ptid;
+  int auxv_len;
 
   if (get_exec_file (0))
     {
@@ -305,6 +412,19 @@ linux_make_note_section (bfd *obfd, int 
       note_data = thread_args.note_data;
     }
 
+  auxv_len = 0;
+  target_read_aux_vector (linux_auxv_count, &auxv_len);
+  if (auxv_len != 0)
+    {
+      bfd_byte *auxv, *auxvptr;
+      auxv = alloca (auxv_len * 2
+		     * (bfd_arch_bits_per_address (exec_bfd) / 8));
+      auxvptr = auxv;
+      target_read_aux_vector (linux_auxv_reconstruct, &auxvptr);
+      note_data = elfcore_write_note (obfd, note_data, note_size,
+				      "CORE", NT_AUXV, auxv, auxvptr - auxv);
+    }
+
   make_cleanup (xfree, note_data);
   return note_data;
 }
@@ -593,9 +713,11 @@ _initialize_linux_proc (void)
 {
   extern void inftarg_set_find_memory_regions ();
   extern void inftarg_set_make_corefile_notes ();
+  extern void inftarg_set_read_aux_vector ();
 
   inftarg_set_find_memory_regions (linux_find_memory_regions);
   inftarg_set_make_corefile_notes (linux_make_note_section);
+  inftarg_set_read_aux_vector (procfs_read_aux_vector);
 
   add_info ("proc", linux_info_proc_cmd,
 	    "Show /proc process information about any running process.\n\
Index: corelow.c
===================================================================
RCS file: /cvs/src/src/gdb/corelow.c,v
retrieving revision 1.30
diff -b -p -u -r1.30 corelow.c
--- corelow.c	21 Sep 2003 01:26:44 -0000	1.30
+++ corelow.c	7 Oct 2003 03:29:27 -0000
@@ -474,6 +550,69 @@ core_files_info (struct target_ops *t)
   print_section_info (t, core_bfd);
 }
 \f
+static int
+core_read_aux_vector (int (*func) (const void *, void *), void *data)
+{
+  sec_ptr section;
+  bfd_size_type size;
+  char *contents;
+  int ret;
+
+  section = bfd_get_section_by_name (core_bfd, ".auxv");
+  if (section == NULL)
+    return 0;
+
+  size = bfd_section_size (core_bfd, section);
+  contents = (char *) alloca (size);
+  if (! bfd_get_section_contents (core_bfd, section, contents,
+				  (file_ptr) 0, size))
+    {
+      warning ("Couldn't read NT_AUXV note in core file.");
+      return 0;
+    }
+
+  switch (bfd_arch_bits_per_address (core_bfd))
+    {
+    default:
+      return 0;
+
+    case 32:
+      {
+	Elf32_External_Auxv *av;
+	for (av = (Elf32_External_Auxv *) contents;
+	     (char *) av < contents + size;
+	     ++av)
+	  {
+	    Elf_Internal_Auxv elt;
+	    elt.a_type = bfd_get_32 (core_bfd, av->a_type);
+	    elt.a_val = bfd_get_32 (core_bfd, av->a_val);
+	    ret = (*func) (&elt, data);
+	    if (ret != 0)
+	      return ret;
+	  }
+	break;
+      }
+    case 64:
+      {
+	Elf64_External_Auxv *av;
+	for (av = (Elf64_External_Auxv *) contents;
+	     (char *) av < contents + size;
+	     ++av)
+	  {
+	    Elf_Internal_Auxv elt;
+	    elt.a_type = bfd_get_64 (core_bfd, av->a_type);
+	    elt.a_val = bfd_get_64 (core_bfd, av->a_val);
+	    ret = (*func) (&elt, data);
+	    if (ret != 0)
+	      return ret;
+	  }
+	break;
+      }
+    }
+
+  return 0;
+}
+\f
 /* If mourn is being called in all the right places, this could be say
    `gdb internal error' (since generic_mourn calls breakpoint_init_inferior).  */
 
@@ -520,6 +659,7 @@ init_core_ops (void)
   core_ops.to_has_memory = 1;
   core_ops.to_has_stack = 1;
   core_ops.to_has_registers = 1;
+  core_ops.to_read_aux_vector = core_read_aux_vector;
   core_ops.to_magic = OPS_MAGIC;
 }