[rfa] Attach vsyscall support for GNU/Linux

[rfa] Attach vsyscall support for GNU/Linux

[Daniel Jacobowitz]

This patch, based on a patch Andrew posted earlier this year, connects
vsyscall support to the inferior_created observer.

As before, I have adjusted the i386-linux sigtramp code to recognize
the names of the kernel trampolines (both of them this time - I forgot
the RT case when I first did this).  And I have adjusted the i386
target to recognize signal trampolines before searching for DWARF-2
unwind information, as previously discussed.  Other architectures which
now have a vsyscall DSO may need to make the same change.

I re-added the inferior_created observer to child_attach; it got lost
in the change to remove ATTACH_DETACH.

I ended up not using from_tty after all.  Instead, I arrange for the
right message to be printed out by the core symfile code.  This causes
the message for reading the DSO's symbols to be printed out iff the
messages for reading other shared libraries are.

Tested on i686-pc-linux-gnu.  There are no changes in testsuite
results, but a couple of places in the logs look better; instead of
getting lucky when trying to backtrace from 0xffffe410, we get a proper
backtrace from __kernel_vsyscall.

OK?  How about for the branch?  I think this patch needs both i386 and
symtab approval.

-- 
Daniel Jacobowitz

2004-10-24  Andrew Cagney  <cagney@redhat.com>
	    Daniel Jacobowitz  <dan@debian.org>
	    Roland McGrath  <roland@redhat.com>

	* Makefile.in (symfile-mem.o): Update dependencies.
	* i386-linux-tdep.c (i386_linux_sigtramp_p): Handle
	__kernel_sigreturn and __kernel_rt_sigreturn.
	* i386-tdep.c (i386_gdbarch_init): Check for signal frames
	before dwarf2 frames.
	* inf-ptrace.c (inf_ptrace_attach): Call
	observer_notify_inferior_created.
	* inftarg.c (child_attach): Likewise.
	* symfile-mem.c: Include "observer.h", "auxv.h", and "elf/common.h".
	(symbol_file_add_from_memory): Take NAME argument.  Use it for
	the new BFD's filename.
	(add_symbol_file_from_memory_command): Update call to
	symbol_file_add_from_memory.
	(struct symbol_file_add_from_memory_args, add_vsyscall_page)
	(symbol_file_add_from_memory_wrapper): New.
	(_initialize_symfile_mem): Register add_vsyscall_page as an
	inferior_created observer.

Index: gdb/Makefile.in
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/Makefile.in,v
retrieving revision 1.643
diff -u -p -r1.643 Makefile.in
--- gdb/Makefile.in	15 Oct 2004 16:17:34 -0000	1.643
+++ gdb/Makefile.in	24 Oct 2004 17:25:24 -0000
@@ -2600,7 +2600,8 @@ symfile.o: symfile.c $(defs_h) $(bfdlink
 	$(hashtab_h) $(readline_h) $(gdb_assert_h) $(block_h) \
 	$(gdb_string_h) $(gdb_stat_h)
 symfile-mem.o: symfile-mem.c $(defs_h) $(symtab_h) $(gdbcore_h) \
-	$(objfiles_h) $(gdbcmd_h) $(target_h) $(value_h) $(symfile_h)
+	$(objfiles_h) $(gdbcmd_h) $(target_h) $(value_h) $(symfile_h) \
+	$(observer_h) $(auxv_h) $(elf_common_h)
 symmisc.o: symmisc.c $(defs_h) $(symtab_h) $(gdbtypes_h) $(bfd_h) \
 	$(symfile_h) $(objfiles_h) $(breakpoint_h) $(command_h) \
 	$(gdb_obstack_h) $(language_h) $(bcache_h) $(block_h) $(gdb_regex_h) \
Index: gdb/i386-linux-tdep.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/i386-linux-tdep.c,v
retrieving revision 1.41
diff -u -p -r1.41 i386-linux-tdep.c
--- gdb/i386-linux-tdep.c	6 Aug 2004 20:58:28 -0000	1.41
+++ gdb/i386-linux-tdep.c	24 Oct 2004 17:48:46 -0000
@@ -231,6 +231,12 @@ i386_linux_sigtramp_p (struct frame_info
 
   find_pc_partial_function (pc, &name, NULL, NULL);
 
+  /* If a vsyscall DSO is in use, the signal trampolines may have these
+     names.  */
+  if (name && (strcmp (name, "__kernel_sigreturn") == 0
+	       || strcmp (name, "__kernel_rt_sigreturn") == 0))
+    return 1;
+
   /* If we have NAME, we can optimize the search.  The trampolines are
      named __restore and __restore_rt.  However, they aren't dynamically
      exported from the shared C library, so the trampoline may appear to
Index: gdb/i386-tdep.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/i386-tdep.c,v
retrieving revision 1.201
diff -u -p -r1.201 i386-tdep.c
--- gdb/i386-tdep.c	18 Sep 2004 20:16:37 -0000	1.201
+++ gdb/i386-tdep.c	24 Oct 2004 17:22:27 -0000
@@ -2216,6 +2216,10 @@ i386_gdbarch_init (struct gdbarch_info i
   /* Helper for function argument information.  */
   set_gdbarch_fetch_pointer_argument (gdbarch, i386_fetch_pointer_argument);
 
+  /* The signal handler might have dwarf2 CFI, via the vsyscall DSO, so check
+     for this first.  */
+  frame_unwind_append_sniffer (gdbarch, i386_sigtramp_frame_sniffer);
+
   /* Hook in the DWARF CFI frame unwinder.  */
   frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
 
@@ -2224,7 +2228,6 @@ i386_gdbarch_init (struct gdbarch_info i
   /* Hook in ABI-specific overrides, if they have been registered.  */
   gdbarch_init_osabi (info, gdbarch);
 
-  frame_unwind_append_sniffer (gdbarch, i386_sigtramp_frame_sniffer);
   frame_unwind_append_sniffer (gdbarch, i386_frame_sniffer);
 
   /* If we have a register mapping, enable the generic core file
Index: gdb/inf-ptrace.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/inf-ptrace.c,v
retrieving revision 1.11
diff -u -p -r1.11 inf-ptrace.c
--- gdb/inf-ptrace.c	15 Oct 2004 13:29:33 -0000	1.11
+++ gdb/inf-ptrace.c	24 Oct 2004 17:23:11 -0000
@@ -220,6 +220,10 @@ inf_ptrace_attach (char *args, int from_
 
   inferior_ptid = pid_to_ptid (pid);
   push_target (ptrace_ops_hack);
+
+  /* Do this first, before anything has had a chance to query the
+     inferior's symbol table or similar.  */
+  observer_notify_inferior_created (&current_target, from_tty);
 }
 
 static void
Index: gdb/inftarg.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/inftarg.c,v
retrieving revision 1.34
diff -u -p -r1.34 inftarg.c
--- gdb/inftarg.c	8 Oct 2004 20:29:47 -0000	1.34
+++ gdb/inftarg.c	24 Oct 2004 17:23:15 -0000
@@ -211,6 +211,10 @@ child_attach (char *args, int from_tty)
   
   inferior_ptid = pid_to_ptid (pid);
   push_target (&deprecated_child_ops);
+
+  /* Do this first, before anything has had a chance to query the
+     inferior's symbol table or similar.  */
+  observer_notify_inferior_created (&current_target, from_tty);
 }
 
 #if !defined(CHILD_POST_ATTACH)
Index: gdb/symfile-mem.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/symfile-mem.c,v
retrieving revision 1.3
diff -u -p -r1.3 symfile-mem.c
--- gdb/symfile-mem.c	17 Jul 2004 14:24:07 -0000	1.3
+++ gdb/symfile-mem.c	24 Oct 2004 18:02:15 -0000
@@ -52,13 +52,19 @@
 #include "target.h"
 #include "value.h"
 #include "symfile.h"
+#include "observer.h"
+#include "auxv.h"
+#include "elf/common.h"
 
 
 /* Read inferior memory at ADDR to find the header of a loaded object file
    and read its in-core symbols out of inferior memory.  TEMPL is a bfd
-   representing the target's format.  */
+   representing the target's format.  NAME is the name to use for this
+   symbol file in messages; it can be NULL or a malloc-allocated string
+   which will be attached to the BFD.  */
 static struct objfile *
-symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr, int from_tty)
+symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr, char *name,
+			     int from_tty)
 {
   struct objfile *objf;
   struct bfd *nbfd;
@@ -75,7 +81,10 @@ symbol_file_add_from_memory (struct bfd 
   if (nbfd == NULL)
     error ("Failed to read a valid object file image from memory.");
 
-  nbfd->filename = xstrdup ("shared object read from target memory");
+  if (name == NULL)
+    nbfd->filename = xstrdup ("shared object read from target memory");
+  else
+    nbfd->filename = name;
 
   if (!bfd_check_format (nbfd, bfd_object))
     {
@@ -129,7 +138,73 @@ add_symbol_file_from_memory_command (cha
     error ("\
 Must use symbol-file or exec-file before add-symbol-file-from-memory.");
 
-  symbol_file_add_from_memory (templ, addr, from_tty);
+  symbol_file_add_from_memory (templ, addr, NULL, from_tty);
+}
+
+/* Arguments for symbol_file_add_from_memory_wrapper.  */
+
+struct symbol_file_add_from_memory_args
+{
+  struct bfd *bfd;
+  CORE_ADDR sysinfo_ehdr;
+  char *name;
+  int from_tty;
+};
+
+/* Wrapper function for symbol_file_add_from_memory, for
+   catch_exceptions.  */
+
+static int
+symbol_file_add_from_memory_wrapper (struct ui_out *uiout, void *data)
+{
+  struct symbol_file_add_from_memory_args *args = data;
+
+  symbol_file_add_from_memory (args->bfd, args->sysinfo_ehdr, args->name,
+			       args->from_tty);
+  return 0;
+}
+
+/* Try to add the symbols for the vsyscall page, if there is one.  This function
+   is called via the inferior_created observer.  */
+
+static void
+add_vsyscall_page (struct target_ops *target, int from_tty)
+{
+  CORE_ADDR sysinfo_ehdr;
+
+  if (target_auxv_search (target, AT_SYSINFO_EHDR, &sysinfo_ehdr) > 0
+      && sysinfo_ehdr != (CORE_ADDR) 0)
+    {
+      struct bfd *bfd;
+      struct symbol_file_add_from_memory_args args;
+
+      if (core_bfd != NULL)
+	bfd = core_bfd;
+      else if (exec_bfd != NULL)
+	bfd = exec_bfd;
+      else
+       /* FIXME: cagney/2004-05-06: Should not require an existing
+	  BFD when trying to create a run-time BFD of the VSYSCALL
+	  page in the inferior.  Unfortunately that's the current
+	  interface so for the moment bail.  Introducing a
+	  ``bfd_runtime'' (a BFD created using the loaded image) file
+	  format should fix this.  */
+	{
+	  warning ("could not load vsyscall page because no executable was specified");
+	  warning ("try using the \"file\" command first");
+	  return;
+	}
+      args.bfd = bfd;
+      args.sysinfo_ehdr = sysinfo_ehdr;
+      xasprintf (&args.name, "system-supplied DSO at 0x%s",
+		 paddr_nz (sysinfo_ehdr));
+      /* Pass zero for FROM_TTY, because the action of loading the
+	 vsyscall DSO was not triggered by the user, even if the user
+	 typed "run" at the TTY.  */
+      args.from_tty = 0;
+      catch_exceptions (uiout, symbol_file_add_from_memory_wrapper,
+			&args, NULL, RETURN_MASK_ALL);
+    }
 }
 
 \f
@@ -143,4 +218,7 @@ Load the symbols out of memory from a dy
 Give an expression for the address of the file's shared object file header.",
            &cmdlist);
 
+  /* Want to know of each new inferior so that it's vsyscall info can
+     be extracted.  */
+  observer_attach_inferior_created (add_vsyscall_page);
 }

Re: [rfa] Attach vsyscall support for GNU/Linux

[Mark Kettenis]

   Date: Sun, 24 Oct 2004 14:53:45 -0400
   From: Daniel Jacobowitz <drow@false.org>

   This patch, based on a patch Andrew posted earlier this year, connects
   vsyscall support to the inferior_created observer.

   As before, I have adjusted the i386-linux sigtramp code to recognize
   the names of the kernel trampolines (both of them this time - I forgot
   the RT case when I first did this).  And I have adjusted the i386
   target to recognize signal trampolines before searching for DWARF-2
   unwind information, as previously discussed.  Other architectures which
   now have a vsyscall DSO may need to make the same change.

I still don't get it.  What exactly was the purpose of adding the
vsyscall DSO if we're not using the DWARF CFI it contains.  Can't the
people who dreamt up this wonderful mechanism fix their implementation
such that it doesn't contain any useless DWARF CFI?  I'm a bit
reluctant to approve this since it'll probably mean that it never get
fixed properly :-(.

But there's another reason why I'm against this patch.  It changes the
order of the unwinders for all the other i386 targets too.  Please
find a way to do this such that it affect Linux only.

Sorry, I didn't realize this before...

Mark

Re: [rfa] Attach vsyscall support for GNU/Linux

[Daniel Jacobowitz]

[Roland, question for you a bit of the way down...]

On Sun, Oct 24, 2004 at 10:54:45PM +0200, Mark Kettenis wrote:
>    Date: Sun, 24 Oct 2004 14:53:45 -0400
>    From: Daniel Jacobowitz <drow@false.org>
> 
>    This patch, based on a patch Andrew posted earlier this year, connects
>    vsyscall support to the inferior_created observer.
> 
>    As before, I have adjusted the i386-linux sigtramp code to recognize
>    the names of the kernel trampolines (both of them this time - I forgot
>    the RT case when I first did this).  And I have adjusted the i386
>    target to recognize signal trampolines before searching for DWARF-2
>    unwind information, as previously discussed.  Other architectures which
>    now have a vsyscall DSO may need to make the same change.
> 
> I still don't get it.  What exactly was the purpose of adding the
> vsyscall DSO if we're not using the DWARF CFI it contains.  Can't the
> people who dreamt up this wonderful mechanism fix their implementation
> such that it doesn't contain any useless DWARF CFI?  I'm a bit
> reluctant to approve this since it'll probably mean that it never get
> fixed properly :-(.

If you mean, why add support for it to GDB: so that we can actually
backtrace from the _other_ things in the vsyscall DSO besides signal
handlers.  The one I'm interested in is the __kernel_vsyscall stub.
I could care less about having CFI for the signal trampolines.

If you mean the purpose of creating it in the first place, it was added
for performance.  The CFI was added for run-time unwinders, and
generally works.  I haven't spent enough time analyzing the problem,
but I think it only generally works - if the off-by-one doesn't change
the unwind data, which it rarely does in practice.

There's no way in DWARF CFI to express the difference between return PC
is "virtual call site" address (as here) and return PC is "resume
address, following call site" (as normally).  It's not amenable to
being expressed, because it is more a property of the call site, but
the unwind information is a property of the call destination.

I just don't think this problem is solvable within the existing CFI.
I don't know whether it is solvable by extending DWARF.  Just to make
sure I'm on the right page, I'll recap one instance of why GDB needs to
know it's found a signal handler.

Here's __kernel_rt_sigreturn (starts at 0xffffe440).
ffffe43f:       90                      nop
ffffe440:       b8 ad 00 00 00          mov    $0xad,%eax
ffffe445:       cd 80                   int    $0x80

Here's the unwind information:
000000c4 00000044 00000084 FDE cie=00000044 pc=ffffe43f..ffffe447
  DW_CFA_def_cfa_expression (DW_OP_breg4: 188; DW_OP_deref)
  DW_CFA_expression: r0 (DW_OP_breg4: 204)
  DW_CFA_expression: r1 (DW_OP_breg4: 200)
  DW_CFA_expression: r2 (DW_OP_breg4: 196)
  DW_CFA_expression: r3 (DW_OP_breg4: 192)
  DW_CFA_expression: r5 (DW_OP_breg4: 184)
  DW_CFA_expression: r6 (DW_OP_breg4: 180)
  DW_CFA_expression: r7 (DW_OP_breg4: 176)
  DW_CFA_expression: r8 (DW_OP_breg4: 216)
  DW_CFA_nop

This is accurate.  It correctly locates the saved values of all
registers.  However, this is the frame_address_in_block problem; if the
first instruction of a function generates a synchronous signal, then
the restored value of r8 (the PC) will point to the first byte of the
function.  GDB will use the unwind information for the previous
function.

I bet you could reproduce the corresponding problem by an extremely
signal-heavy stress test using NPTL and asynchronous cancellation.
Roland, am I missing something?  Won't we go off into never-never land
if we're at the first instruction of a function call when a signal is
received and we try to do a forced unwind?

Unwinding bugs aside, I think it's valuable for GDB to know that it is
at a signal trampoline.  I think the custom display in backtrace is
valuable.  That means we should look for signal handlers before looking
for CFI.  For NPTL that value judgement would fall the other way - not
having to special-case signal handlers is a clear win.

> But there's another reason why I'm against this patch.  It changes the
> order of the unwinders for all the other i386 targets too.  Please
> find a way to do this such that it affect Linux only.
> 
> Sorry, I didn't realize this before...

OK, if the rest of the patch reaches consensus I will try to figure out
how to do this.  It will probably just require conditional action based
on the osabi enum.  Not hard.

-- 
Daniel Jacobowitz

Re: [rfa] Attach vsyscall support for GNU/Linux

[Mark Kettenis]

   Date: Sun, 24 Oct 2004 19:16:36 -0400
   From: Daniel Jacobowitz <drow@false.org>

Thanks for the explanation Daniel!

   Unwinding bugs aside, I think it's valuable for GDB to know that it is
   at a signal trampoline.  I think the custom display in backtrace is
   valuable.  That means we should look for signal handlers before looking
   for CFI.  For NPTL that value judgement would fall the other way - not
   having to special-case signal handlers is a clear win.

Given the fact that it is desirable for GDB to know that it's dealing
with a signal handler, I think the correct approach is to extend the
DWARF2 unwinder with a method to get the frame type, similar to what
we already do for pre-initializing the register state.

I'll see if I can come up with a patch for you to test.

Cheers,

Mark

Re: [rfa] Attach vsyscall support for GNU/Linux

[Andrew Cagney]

Mark Kettenis wrote:
>    Date: Sun, 24 Oct 2004 19:16:36 -0400
>    From: Daniel Jacobowitz <drow@false.org>
> 
> Thanks for the explanation Daniel!
> 
>    Unwinding bugs aside, I think it's valuable for GDB to know that it is
>    at a signal trampoline.  I think the custom display in backtrace is
>    valuable.  That means we should look for signal handlers before looking
>    for CFI.  For NPTL that value judgement would fall the other way - not
>    having to special-case signal handlers is a clear win.
> 
> Given the fact that it is desirable for GDB to know that it's dealing
> with a signal handler, I think the correct approach is to extend the
> DWARF2 unwinder with a method to get the frame type, similar to what
> we already do for pre-initializing the register state.

The ``correct approach'' is both more complicated and simplier (the 
complexity comes with the amount of refactoring, the simplicity from the 
result):

At present we've the relationship:

    FRAME <>---- UNWINDER
      <>
       |
    FUNCTION ---> SYMBOL

where the UNWINDER is providing attributes and methods such as:

   - unwind register
   - callee frame?

while the FUNCTION provides attributes such as:

   - code start/range
   - function name

It needs to be changed so more like:

                    SYMBOL
                     /|\
                      |
    FRAME <>----- FUNCTION <>------ UNWINDER

and have the FUNCTION provide:

   - signal trampoline?
   - code start/range
   - function name

and the FUNCTION's unwinder just supply registers.  For the case being 
discussed, this would let us equally implement:

     FRAME <>----- SIGTRAMP-FUNCTION <>----- DWARF2-UNWINDER

     FRAME <>----- SIGTRAMP-FUNCTION <>----- SIGTRAMP-UNWINDER

     FRAME <>----- SIGTRAMP-FUNCTION <>----- UNWINDER-PROXY

(for the last case, the actual unwinder being selected if/when needed).

On the down side, this means replacing the frame identification 
heuristic found in frame-unwind with robust logic in the symtab, and 
expanding symbol.

On the upside, this means that the function symbol starts correctly 
identifying these probed frames (at present the're all b-).

Andrew

Re: [rfa] Attach vsyscall support for GNU/Linux

[Andrew Cagney]

>>But there's another reason why I'm against this patch.  It changes the
>>order of the unwinders for all the other i386 targets too.  Please
>>find a way to do this such that it affect Linux only.
>>
>>Sorry, I didn't realize this before...

I'd not get too hung up on this one.  The current frame-unwind code 
sniff heuristic came about because it ``worked for me''.   We're going 
to have to eventually replace it with something more complicated and 
until then, what ever.

Sniffing a signal frame definitly takes higher priority than sniffing a 
normal frame.

> OK, if the rest of the patch reaches consensus I will try to figure out
> how to do this.  It will probably just require conditional action based
> on the osabi enum.  Not hard.

Andrew

Re: [rfa] Attach vsyscall support for GNU/Linux

[Roland McGrath]

I'm punting this to Jakub as the person more knowledgeable about how the
unwind info is used for exception handling in glibc.

> I just don't think this problem is solvable within the existing CFI.
> I don't know whether it is solvable by extending DWARF.  Just to make
> sure I'm on the right page, I'll recap one instance of why GDB needs to
> know it's found a signal handler.
> 
> Here's __kernel_rt_sigreturn (starts at 0xffffe440).
> ffffe43f:       90                      nop
> ffffe440:       b8 ad 00 00 00          mov    $0xad,%eax
> ffffe445:       cd 80                   int    $0x80
> 
> Here's the unwind information:
> 000000c4 00000044 00000084 FDE cie=00000044 pc=ffffe43f..ffffe447
>   DW_CFA_def_cfa_expression (DW_OP_breg4: 188; DW_OP_deref)
>   DW_CFA_expression: r0 (DW_OP_breg4: 204)
>   DW_CFA_expression: r1 (DW_OP_breg4: 200)
>   DW_CFA_expression: r2 (DW_OP_breg4: 196)
>   DW_CFA_expression: r3 (DW_OP_breg4: 192)
>   DW_CFA_expression: r5 (DW_OP_breg4: 184)
>   DW_CFA_expression: r6 (DW_OP_breg4: 180)
>   DW_CFA_expression: r7 (DW_OP_breg4: 176)
>   DW_CFA_expression: r8 (DW_OP_breg4: 216)
>   DW_CFA_nop
> 
> This is accurate.  It correctly locates the saved values of all
> registers.  However, this is the frame_address_in_block problem; if the
> first instruction of a function generates a synchronous signal, then
> the restored value of r8 (the PC) will point to the first byte of the
> function.  GDB will use the unwind information for the previous
> function.
> 
> I bet you could reproduce the corresponding problem by an extremely
> signal-heavy stress test using NPTL and asynchronous cancellation.
> Roland, am I missing something?  Won't we go off into never-never land
> if we're at the first instruction of a function call when a signal is
> received and we try to do a forced unwind?

Re: [rfa] Attach vsyscall support for GNU/Linux

[Jakub Jelinek]

On Mon, Oct 25, 2004 at 07:51:26PM -0700, Roland McGrath wrote:
> > I just don't think this problem is solvable within the existing CFI.
> > I don't know whether it is solvable by extending DWARF.  Just to make
> > sure I'm on the right page, I'll recap one instance of why GDB needs to
> > know it's found a signal handler.
> > 
> > Here's __kernel_rt_sigreturn (starts at 0xffffe440).
> > ffffe43f:       90                      nop
> > ffffe440:       b8 ad 00 00 00          mov    $0xad,%eax
> > ffffe445:       cd 80                   int    $0x80
> > 
> > Here's the unwind information:
> > 000000c4 00000044 00000084 FDE cie=00000044 pc=ffffe43f..ffffe447
> >   DW_CFA_def_cfa_expression (DW_OP_breg4: 188; DW_OP_deref)
> >   DW_CFA_expression: r0 (DW_OP_breg4: 204)
> >   DW_CFA_expression: r1 (DW_OP_breg4: 200)
> >   DW_CFA_expression: r2 (DW_OP_breg4: 196)
> >   DW_CFA_expression: r3 (DW_OP_breg4: 192)
> >   DW_CFA_expression: r5 (DW_OP_breg4: 184)
> >   DW_CFA_expression: r6 (DW_OP_breg4: 180)
> >   DW_CFA_expression: r7 (DW_OP_breg4: 176)
> >   DW_CFA_expression: r8 (DW_OP_breg4: 216)
> >   DW_CFA_nop
> > 
> > This is accurate.  It correctly locates the saved values of all
> > registers.  However, this is the frame_address_in_block problem; if the
> > first instruction of a function generates a synchronous signal, then
> > the restored value of r8 (the PC) will point to the first byte of the
> > function.  GDB will use the unwind information for the previous
> > function.
> > 
> > I bet you could reproduce the corresponding problem by an extremely
> > signal-heavy stress test using NPTL and asynchronous cancellation.
> > Roland, am I missing something?  Won't we go off into never-never land
> > if we're at the first instruction of a function call when a signal is
> > received and we try to do a forced unwind?

Yeah, this is a known problem, but not yet dealt with.
See http://sources.redhat.com/bugzilla/show_bug.cgi?id=300
for details.
Option Three in Richard's #7 comment sounds the best thing to do, but
I didn't get to implement it yet.

	Jakub

Re: [rfa] Attach vsyscall support for GNU/Linux

[Daniel Jacobowitz]

On Tue, Oct 26, 2004 at 04:17:44AM -0400, Jakub Jelinek wrote:
> On Mon, Oct 25, 2004 at 07:51:26PM -0700, Roland McGrath wrote:
> > > I just don't think this problem is solvable within the existing CFI.
> > > I don't know whether it is solvable by extending DWARF.  Just to make
> > > sure I'm on the right page, I'll recap one instance of why GDB needs to
> > > know it's found a signal handler.
> > > 
> > > Here's __kernel_rt_sigreturn (starts at 0xffffe440).
> > > ffffe43f:       90                      nop
> > > ffffe440:       b8 ad 00 00 00          mov    $0xad,%eax
> > > ffffe445:       cd 80                   int    $0x80
> > > 
> > > Here's the unwind information:
> > > 000000c4 00000044 00000084 FDE cie=00000044 pc=ffffe43f..ffffe447
> > >   DW_CFA_def_cfa_expression (DW_OP_breg4: 188; DW_OP_deref)
> > >   DW_CFA_expression: r0 (DW_OP_breg4: 204)
> > >   DW_CFA_expression: r1 (DW_OP_breg4: 200)
> > >   DW_CFA_expression: r2 (DW_OP_breg4: 196)
> > >   DW_CFA_expression: r3 (DW_OP_breg4: 192)
> > >   DW_CFA_expression: r5 (DW_OP_breg4: 184)
> > >   DW_CFA_expression: r6 (DW_OP_breg4: 180)
> > >   DW_CFA_expression: r7 (DW_OP_breg4: 176)
> > >   DW_CFA_expression: r8 (DW_OP_breg4: 216)
> > >   DW_CFA_nop
> > > 
> > > This is accurate.  It correctly locates the saved values of all
> > > registers.  However, this is the frame_address_in_block problem; if the
> > > first instruction of a function generates a synchronous signal, then
> > > the restored value of r8 (the PC) will point to the first byte of the
> > > function.  GDB will use the unwind information for the previous
> > > function.
> > > 
> > > I bet you could reproduce the corresponding problem by an extremely
> > > signal-heavy stress test using NPTL and asynchronous cancellation.
> > > Roland, am I missing something?  Won't we go off into never-never land
> > > if we're at the first instruction of a function call when a signal is
> > > received and we try to do a forced unwind?
> 
> Yeah, this is a known problem, but not yet dealt with.
> See http://sources.redhat.com/bugzilla/show_bug.cgi?id=300
> for details.
> Option Three in Richard's #7 comment sounds the best thing to do, but
> I didn't get to implement it yet.

Thanks for the pointer!  I've been thinking about #2; I'm not quite
sure about #3.  What would the expresson be used for - "evaluates
non-zero" for what condition?

[I've also needed something like DW_CFA_expression that didn't evaluate
to a location before; if that would be useful to solve this, then we
ought to add it.]

-- 
Daniel Jacobowitz

Re: [rfa] Attach vsyscall support for GNU/Linux

[Daniel Jacobowitz]

On Tue, Oct 26, 2004 at 12:12:26AM +0200, Mark Kettenis wrote:
>    Date: Sun, 24 Oct 2004 19:16:36 -0400
>    From: Daniel Jacobowitz <drow@false.org>
> 
> Thanks for the explanation Daniel!
> 
>    Unwinding bugs aside, I think it's valuable for GDB to know that it is
>    at a signal trampoline.  I think the custom display in backtrace is
>    valuable.  That means we should look for signal handlers before looking
>    for CFI.  For NPTL that value judgement would fall the other way - not
>    having to special-case signal handlers is a clear win.
> 
> Given the fact that it is desirable for GDB to know that it's dealing
> with a signal handler, I think the correct approach is to extend the
> DWARF2 unwinder with a method to get the frame type, similar to what
> we already do for pre-initializing the register state.
> 
> I'll see if I can come up with a patch for you to test.

Had any time for this, Mark?  If not, I can try it.

I think this patch is very important for 6.3.

-- 
Daniel Jacobowitz

Re: [rfa] Attach vsyscall support for GNU/Linux

[Mark Kettenis]

   Date: Mon, 1 Nov 2004 11:15:52 -0500
   From: Daniel Jacobowitz <drow@false.org>

   On Tue, Oct 26, 2004 at 12:12:26AM +0200, Mark Kettenis wrote:
   >    Date: Sun, 24 Oct 2004 19:16:36 -0400
   >    From: Daniel Jacobowitz <drow@false.org>
   > 
   > Thanks for the explanation Daniel!
   > 
   >    Unwinding bugs aside, I think it's valuable for GDB to know that it is
   >    at a signal trampoline.  I think the custom display in backtrace is
   >    valuable.  That means we should look for signal handlers before looking
   >    for CFI.  For NPTL that value judgement would fall the other way - not
   >    having to special-case signal handlers is a clear win.
   > 
   > Given the fact that it is desirable for GDB to know that it's dealing
   > with a signal handler, I think the correct approach is to extend the
   > DWARF2 unwinder with a method to get the frame type, similar to what
   > we already do for pre-initializing the register state.
   > 
   > I'll see if I can come up with a patch for you to test.

   Had any time for this, Mark?  If not, I can try it.

I forgot about it :-(.  I had a look just now, but unfortunately it's
not as easy as I thought.  The frame type is currently hard-coded in
the unwinder.  This is wrong, but Andrew thinks it's wrong in a
different way than I.  At least, that's what I think.  I'll have to
learn reading UML diagrams first.  I'll throw some Feynman diagrams
into my next mail to get even with him ;-).  This is not going to be a
simple fix, therefore...

   I think this patch is very important for 6.3.

...you might want to convince Andrew to include your origional patch
in 6.3.  Or better yet, a patch that prepends a signal frame unwinder
only for Linux.  If you succeed, you have my blessing to check this in
on mainline too, provided you add a big fat warning why this is done
and that it's so wrong.

Sorry,

Mark

Re: [rfa] Attach vsyscall support for GNU/Linux

[Mark Kettenis]

   Date: Mon, 25 Oct 2004 18:44:37 -0400
   From: Andrew Cagney <cagney@gnu.org>

Thos funny little diagrams are UML isn't it?

   It needs to be changed so more like:

		       SYMBOL
			/|\
			 |
       FRAME <>----- FUNCTION <>------ UNWINDER

   and have the FUNCTION provide:

      - signal trampoline?

I think this is wrong.  It's probably true that functions that are
used as signal trampolines in traditional UNIX systems are only usable
as such, this is not true for interrupt handlers.  On i386 systems you
can write interrupt handlers that are also usable as trap handlers.
Where interrupt handlers are sigtramp-like, trap handlers are musch
more normal.  This kind of attributes depend more on the context and
thereforeit is more logical to put them in the frame.  I think the
same is true for the unwinder.

That said, it is perfectly reasonable to let the frame inherit some of
these attributes from the function.

Mark

Re: [rfa] Attach vsyscall support for GNU/Linux

[Daniel Jacobowitz]

On Mon, Nov 01, 2004 at 09:45:20PM +0100, Mark Kettenis wrote:
>    I think this patch is very important for 6.3.
> 
> ...you might want to convince Andrew to include your origional patch
> in 6.3.  Or better yet, a patch that prepends a signal frame unwinder
> only for Linux.  If you succeed, you have my blessing to check this in
> on mainline too, provided you add a big fat warning why this is done
> and that it's so wrong.

In that case, I'll just wait while you come to an agreement.  I've been
applying vsyscall patches to the Debian GDB package since 6.1; I can do
it for another release.

-- 
Daniel Jacobowitz

Re: [rfa] Attach vsyscall support for GNU/Linux

[Andrew Cagney]

Mark Kettenis wrote:
>    Date: Mon, 25 Oct 2004 18:44:37 -0400
>    From: Andrew Cagney <cagney@gnu.org>
> 
> Thos funny little diagrams are UML isn't it?
> 
>    It needs to be changed so more like:
> 
> 		       SYMBOL
> 			/|\
> 			 |
>        FRAME <>----- FUNCTION <>------ UNWINDER
> 
>    and have the FUNCTION provide:
> 
>       - signal trampoline?

In english:

frame has-a function
function has-a unwinder
function is-a symbol

> I think this is wrong.  It's probably true that functions that are
> used as signal trampolines in traditional UNIX systems are only usable
> as such, this is not true for interrupt handlers.  On i386 systems you
> can write interrupt handlers that are also usable as trap handlers.
> Where interrupt handlers are sigtramp-like, trap handlers are musch
> more normal.  This kind of attributes depend more on the context and
> thereforeit is more logical to put them in the frame.  I think the
> same is true for the unwinder.
> 
> That said, it is perfectly reasonable to let the frame inherit some of
> these attributes from the function.
> 
> Mark
> 

Re: [rfa] Attach vsyscall support for GNU/Linux

[Andrew Cagney]

Daniel Jacobowitz wrote:
> On Mon, Nov 01, 2004 at 09:45:20PM +0100, Mark Kettenis wrote:
> 
>>   I think this patch is very important for 6.3.
>>
>>...you might want to convince Andrew to include your origional patch
>>in 6.3.  Or better yet, a patch that prepends a signal frame unwinder
>>only for Linux.  If you succeed, you have my blessing to check this in
>>on mainline too, provided you add a big fat warning why this is done
>>and that it's so wrong.
> 
> 
> In that case, I'll just wait while you come to an agreement.  I've been
> applying vsyscall patches to the Debian GDB package since 6.1; I can do
> it for another release.

Can you translate the above into code?  At present it's i386 so what 
would I care?

Andrew

Re: [rfa] Attach vsyscall support for GNU/Linux

[Daniel Jacobowitz]

On Mon, Nov 01, 2004 at 09:45:20PM +0100, Mark Kettenis wrote:
> I forgot about it :-(.  I had a look just now, but unfortunately it's
> not as easy as I thought.  The frame type is currently hard-coded in
> the unwinder.  This is wrong, but Andrew thinks it's wrong in a
> different way than I.  At least, that's what I think.  I'll have to
> learn reading UML diagrams first.  I'll throw some Feynman diagrams
> into my next mail to get even with him ;-).  This is not going to be a
> simple fix, therefore...

How about this, in the meantime?  If you don't like the approach, I'll
wait until we can properly decide the relationship between unwinders
and frame types.

This patch adds a new sniffer, dwarf2_signal_frame_sniffer, which will
only accept the frame if an architecture-specific hook has claimed that
this is a signal frame (i386 GNU/Linux provides one that works by
name).  However, we then use the CFI normally - the only difference is
that the result has SIGTRAMP_FRAME as its type.  It works beautifully! 
Tested on i386-pc-linux-gnu, with vsyscall DSO.

-- 
Daniel Jacobowitz

2004-11-05  Andrew Cagney  <cagney@redhat.com>
	    Daniel Jacobowitz  <dan@debian.org>
	    Roland McGrath  <roland@redhat.com>

	* Makefile.in (symfile-mem.o): Update dependencies.
	* dwarf2-frame.c (struct dwarf2_frame_ops): Add signal_frame_p.
	(dwarf2_frame_set_signal_frame_p, dwarf2_frame_signal_frame_p)
	(dwarf2_signal_frame_unwind, dwarf2_signal_frame_sniffer): New.
	* dwarf2-frame.h (dwarf2_frame_set_signal_frame_p)
	(dwarf2_signal_frame_sniffer): New prototypes.
	* i386-linux-tdep.c (i386_linux_dwarf_signal_frame_p): New.
	(i386_linux_init_abi): Call dwarf2_frame_set_signal_frame_p.
	* i386-tdep.c (i386_gdbarch_init): Append dwarf2_signal_frame_sniffer
	before dwarf2_frame_sniffer.
	* inf-ptrace.c (inf_ptrace_attach): Call
	observer_notify_inferior_created.
	* inftarg.c (child_attach): Likewise.
	* symfile-mem.c: Include "observer.h", "auxv.h", and "elf/common.h".
	(symbol_file_add_from_memory): Take NAME argument.  Use it for
	the new BFD's filename.
	(add_symbol_file_from_memory_command): Update call to
	symbol_file_add_from_memory.
	(struct symbol_file_add_from_memory_args, add_vsyscall_page)
	(symbol_file_add_from_memory_wrapper): New.
	(_initialize_symfile_mem): Register add_vsyscall_page as an
	inferior_created observer.

Index: gdb/Makefile.in
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/Makefile.in,v
retrieving revision 1.654
diff -u -p -r1.654 Makefile.in
--- gdb/Makefile.in	4 Nov 2004 02:15:19 -0000	1.654
+++ gdb/Makefile.in	5 Nov 2004 20:10:05 -0000
@@ -2619,7 +2619,8 @@ symfile.o: symfile.c $(defs_h) $(bfdlink
 	$(hashtab_h) $(readline_h) $(gdb_assert_h) $(block_h) \
 	$(gdb_string_h) $(gdb_stat_h)
 symfile-mem.o: symfile-mem.c $(defs_h) $(symtab_h) $(gdbcore_h) \
-	$(objfiles_h) $(gdbcmd_h) $(target_h) $(value_h) $(symfile_h)
+	$(objfiles_h) $(gdbcmd_h) $(target_h) $(value_h) $(symfile_h) \
+	$(observer_h) $(auxv_h) $(elf_common_h)
 symmisc.o: symmisc.c $(defs_h) $(symtab_h) $(gdbtypes_h) $(bfd_h) \
 	$(symfile_h) $(objfiles_h) $(breakpoint_h) $(command_h) \
 	$(gdb_obstack_h) $(language_h) $(bcache_h) $(block_h) $(gdb_regex_h) \
Index: gdb/dwarf2-frame.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/dwarf2-frame.c,v
retrieving revision 1.41
diff -u -p -r1.41 dwarf2-frame.c
--- gdb/dwarf2-frame.c	4 Nov 2004 21:15:15 -0000	1.41
+++ gdb/dwarf2-frame.c	5 Nov 2004 20:33:55 -0000
@@ -471,6 +471,10 @@ struct dwarf2_frame_ops
 {
   /* Pre-initialize the register state REG for register REGNUM.  */
   void (*init_reg) (struct gdbarch *, int, struct dwarf2_frame_state_reg *);
+
+  /* Check whether the frame preceding NEXT_FRAME will be a signal
+     trampoline.  */
+  int (*signal_frame_p) (struct gdbarch *, struct frame_info *);
 };
 
 /* Default architecture-specific register state initialization
@@ -547,6 +551,33 @@ dwarf2_frame_init_reg (struct gdbarch *g
 
   ops->init_reg (gdbarch, regnum, reg);
 }
+
+/* Set the architecture-specific signal trampoline recognition
+   function for GDBARCH to SIGNAL_FRAME_P.  */
+
+void
+dwarf2_frame_set_signal_frame_p (struct gdbarch *gdbarch,
+				 int (*signal_frame_p) (struct gdbarch *,
+							struct frame_info *))
+{
+  struct dwarf2_frame_ops *ops = gdbarch_data (gdbarch, dwarf2_frame_data);
+
+  ops->signal_frame_p = signal_frame_p;
+}
+
+/* Query the architecture-specific signal frame recognizer for
+   NEXT_FRAME.  */
+
+static int
+dwarf2_frame_signal_frame_p (struct gdbarch *gdbarch,
+			     struct frame_info *next_frame)
+{
+  struct dwarf2_frame_ops *ops = gdbarch_data (gdbarch, dwarf2_frame_data);
+
+  if (ops->signal_frame_p == NULL)
+    return 0;
+  return ops->signal_frame_p (gdbarch, next_frame);
+}
 \f
 
 struct dwarf2_frame_cache
@@ -853,6 +884,28 @@ dwarf2_frame_sniffer (struct frame_info 
 
   return NULL;
 }
+
+static const struct frame_unwind dwarf2_signal_frame_unwind =
+{
+  SIGTRAMP_FRAME,
+  dwarf2_frame_this_id,
+  dwarf2_frame_prev_register
+};
+
+const struct frame_unwind *
+dwarf2_signal_frame_sniffer (struct frame_info *next_frame)
+{
+  /* On some targets, signal trampolines may have unwind information.
+     We need to recognize them so that we set the frame type correctly
+     (to SIGNAL_FRAME).  */
+
+  if (dwarf2_frame_signal_frame_p (get_frame_arch (next_frame),
+				   next_frame)
+      && dwarf2_frame_sniffer (next_frame) != NULL)
+    return &dwarf2_signal_frame_unwind;
+
+  return NULL;
+}
 \f
 
 /* There is no explicitly defined relationship between the CFA and the
Index: gdb/dwarf2-frame.h
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/dwarf2-frame.h,v
retrieving revision 1.6
diff -u -p -r1.6 dwarf2-frame.h
--- gdb/dwarf2-frame.h	28 Feb 2004 16:59:32 -0000	1.6
+++ gdb/dwarf2-frame.h	5 Nov 2004 20:22:36 -0000
@@ -79,12 +79,26 @@ extern void dwarf2_frame_set_init_reg (s
 				       void (*init_reg) (struct gdbarch *, int,
 					     struct dwarf2_frame_state_reg *));
 
+/* Set the architecture-specific signal trampoline recognition
+   function for GDBARCH to SIGNAL_FRAME_P.  */
+
+extern void
+  dwarf2_frame_set_signal_frame_p (struct gdbarch *gdbarch,
+				   int (*signal_frame_p) (struct gdbarch *,
+							  struct frame_info *));
+
 /* Return the frame unwind methods for the function that contains PC,
    or NULL if it can't be handled by DWARF CFI frame unwinder.  */
 
 extern const struct frame_unwind *
   dwarf2_frame_sniffer (struct frame_info *next_frame);
 
+/* Return the frame unwind methods for the function that contains PC,
+   or NULL if it is not a signal frame with DWARF CFI.  */
+
+extern const struct frame_unwind *
+  dwarf2_signal_frame_sniffer (struct frame_info *next_frame);
+
 /* Return the frame base methods for the function that contains PC, or
    NULL if it can't be handled by the DWARF CFI frame unwinder.  */
 
Index: gdb/i386-linux-tdep.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/i386-linux-tdep.c,v
retrieving revision 1.41
diff -u -p -r1.41 i386-linux-tdep.c
--- gdb/i386-linux-tdep.c	6 Aug 2004 20:58:28 -0000	1.41
+++ gdb/i386-linux-tdep.c	5 Nov 2004 20:24:29 -0000
@@ -244,6 +244,27 @@ i386_linux_sigtramp_p (struct frame_info
 	  || strcmp ("__restore_rt", name) == 0);
 }
 
+/* Return one if the unwound PC from NEXT_FRAME is in a signal trampoline
+   which may have DWARF-2 CFI.  */
+
+static int
+i386_linux_dwarf_signal_frame_p (struct gdbarch *gdbarch,
+				 struct frame_info *next_frame)
+{
+  CORE_ADDR pc = frame_pc_unwind (next_frame);
+  char *name;
+
+  find_pc_partial_function (pc, &name, NULL, NULL);
+
+  /* If a vsyscall DSO is in use, the signal trampolines may have these
+     names.  */
+  if (name && (strcmp (name, "__kernel_sigreturn") == 0
+	       || strcmp (name, "__kernel_rt_sigreturn") == 0))
+    return 1;
+
+  return 0;
+}
+
 /* Offset to struct sigcontext in ucontext, from <asm/ucontext.h>.  */
 #define I386_LINUX_UCONTEXT_SIGCONTEXT_OFFSET 20
 
@@ -414,6 +435,8 @@ i386_linux_init_abi (struct gdbarch_info
 
   /* GNU/Linux uses the dynamic linker included in the GNU C Library.  */
   set_gdbarch_skip_solib_resolver (gdbarch, glibc_skip_solib_resolver);
+
+  dwarf2_frame_set_signal_frame_p (gdbarch, i386_linux_dwarf_signal_frame_p);
 }
 
 /* Provide a prototype to silence -Wmissing-prototypes.  */
Index: gdb/i386-tdep.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/i386-tdep.c,v
retrieving revision 1.203
diff -u -p -r1.203 i386-tdep.c
--- gdb/i386-tdep.c	31 Oct 2004 19:52:46 -0000	1.203
+++ gdb/i386-tdep.c	5 Nov 2004 20:20:46 -0000
@@ -2223,6 +2223,10 @@ i386_gdbarch_init (struct gdbarch_info i
   /* Helper for function argument information.  */
   set_gdbarch_fetch_pointer_argument (gdbarch, i386_fetch_pointer_argument);
 
+  /* The signal handler might have dwarf2 CFI, via the GNU/Linux
+     vsyscall DSO, so check for this first.  */
+  frame_unwind_append_sniffer (gdbarch, dwarf2_signal_frame_sniffer);
+
   /* Hook in the DWARF CFI frame unwinder.  */
   frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
 
Index: gdb/inf-ptrace.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/inf-ptrace.c,v
retrieving revision 1.11
diff -u -p -r1.11 inf-ptrace.c
--- gdb/inf-ptrace.c	15 Oct 2004 13:29:33 -0000	1.11
+++ gdb/inf-ptrace.c	5 Nov 2004 20:10:05 -0000
@@ -220,6 +220,10 @@ inf_ptrace_attach (char *args, int from_
 
   inferior_ptid = pid_to_ptid (pid);
   push_target (ptrace_ops_hack);
+
+  /* Do this first, before anything has had a chance to query the
+     inferior's symbol table or similar.  */
+  observer_notify_inferior_created (&current_target, from_tty);
 }
 
 static void
Index: gdb/inftarg.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/inftarg.c,v
retrieving revision 1.34
diff -u -p -r1.34 inftarg.c
--- gdb/inftarg.c	8 Oct 2004 20:29:47 -0000	1.34
+++ gdb/inftarg.c	5 Nov 2004 20:10:05 -0000
@@ -211,6 +211,10 @@ child_attach (char *args, int from_tty)
   
   inferior_ptid = pid_to_ptid (pid);
   push_target (&deprecated_child_ops);
+
+  /* Do this first, before anything has had a chance to query the
+     inferior's symbol table or similar.  */
+  observer_notify_inferior_created (&current_target, from_tty);
 }
 
 #if !defined(CHILD_POST_ATTACH)
Index: gdb/symfile-mem.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/symfile-mem.c,v
retrieving revision 1.3
diff -u -p -r1.3 symfile-mem.c
--- gdb/symfile-mem.c	17 Jul 2004 14:24:07 -0000	1.3
+++ gdb/symfile-mem.c	5 Nov 2004 20:10:05 -0000
@@ -52,13 +52,19 @@
 #include "target.h"
 #include "value.h"
 #include "symfile.h"
+#include "observer.h"
+#include "auxv.h"
+#include "elf/common.h"
 
 
 /* Read inferior memory at ADDR to find the header of a loaded object file
    and read its in-core symbols out of inferior memory.  TEMPL is a bfd
-   representing the target's format.  */
+   representing the target's format.  NAME is the name to use for this
+   symbol file in messages; it can be NULL or a malloc-allocated string
+   which will be attached to the BFD.  */
 static struct objfile *
-symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr, int from_tty)
+symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr, char *name,
+			     int from_tty)
 {
   struct objfile *objf;
   struct bfd *nbfd;
@@ -75,7 +81,10 @@ symbol_file_add_from_memory (struct bfd 
   if (nbfd == NULL)
     error ("Failed to read a valid object file image from memory.");
 
-  nbfd->filename = xstrdup ("shared object read from target memory");
+  if (name == NULL)
+    nbfd->filename = xstrdup ("shared object read from target memory");
+  else
+    nbfd->filename = name;
 
   if (!bfd_check_format (nbfd, bfd_object))
     {
@@ -129,7 +138,73 @@ add_symbol_file_from_memory_command (cha
     error ("\
 Must use symbol-file or exec-file before add-symbol-file-from-memory.");
 
-  symbol_file_add_from_memory (templ, addr, from_tty);
+  symbol_file_add_from_memory (templ, addr, NULL, from_tty);
+}
+
+/* Arguments for symbol_file_add_from_memory_wrapper.  */
+
+struct symbol_file_add_from_memory_args
+{
+  struct bfd *bfd;
+  CORE_ADDR sysinfo_ehdr;
+  char *name;
+  int from_tty;
+};
+
+/* Wrapper function for symbol_file_add_from_memory, for
+   catch_exceptions.  */
+
+static int
+symbol_file_add_from_memory_wrapper (struct ui_out *uiout, void *data)
+{
+  struct symbol_file_add_from_memory_args *args = data;
+
+  symbol_file_add_from_memory (args->bfd, args->sysinfo_ehdr, args->name,
+			       args->from_tty);
+  return 0;
+}
+
+/* Try to add the symbols for the vsyscall page, if there is one.  This function
+   is called via the inferior_created observer.  */
+
+static void
+add_vsyscall_page (struct target_ops *target, int from_tty)
+{
+  CORE_ADDR sysinfo_ehdr;
+
+  if (target_auxv_search (target, AT_SYSINFO_EHDR, &sysinfo_ehdr) > 0
+      && sysinfo_ehdr != (CORE_ADDR) 0)
+    {
+      struct bfd *bfd;
+      struct symbol_file_add_from_memory_args args;
+
+      if (core_bfd != NULL)
+	bfd = core_bfd;
+      else if (exec_bfd != NULL)
+	bfd = exec_bfd;
+      else
+       /* FIXME: cagney/2004-05-06: Should not require an existing
+	  BFD when trying to create a run-time BFD of the VSYSCALL
+	  page in the inferior.  Unfortunately that's the current
+	  interface so for the moment bail.  Introducing a
+	  ``bfd_runtime'' (a BFD created using the loaded image) file
+	  format should fix this.  */
+	{
+	  warning ("could not load vsyscall page because no executable was specified");
+	  warning ("try using the \"file\" command first");
+	  return;
+	}
+      args.bfd = bfd;
+      args.sysinfo_ehdr = sysinfo_ehdr;
+      xasprintf (&args.name, "system-supplied DSO at 0x%s",
+		 paddr_nz (sysinfo_ehdr));
+      /* Pass zero for FROM_TTY, because the action of loading the
+	 vsyscall DSO was not triggered by the user, even if the user
+	 typed "run" at the TTY.  */
+      args.from_tty = 0;
+      catch_exceptions (uiout, symbol_file_add_from_memory_wrapper,
+			&args, NULL, RETURN_MASK_ALL);
+    }
 }
 
 \f
@@ -143,4 +218,7 @@ Load the symbols out of memory from a dy
 Give an expression for the address of the file's shared object file header.",
            &cmdlist);
 
+  /* Want to know of each new inferior so that it's vsyscall info can
+     be extracted.  */
+  observer_attach_inferior_created (add_vsyscall_page);
 }

Re: [rfa] Attach vsyscall support for GNU/Linux

[Mark Kettenis]

   Date: Fri, 5 Nov 2004 18:42:30 -0500
   From: Daniel Jacobowitz <drow@false.org>

   How about this, in the meantime?  If you don't like the approach, I'll
   wait until we can properly decide the relationship between unwinders
   and frame types.

   This patch adds a new sniffer, dwarf2_signal_frame_sniffer, which will
   only accept the frame if an architecture-specific hook has claimed that
   this is a signal frame (i386 GNU/Linux provides one that works by
   name).  However, we then use the CFI normally - the only difference is
   that the result has SIGTRAMP_FRAME as its type.  It works beautifully! 
   Tested on i386-pc-linux-gnu, with vsyscall DSO.

Within the current framework this seems to be a reasonable approach.
Actually it's a lot less invasive than I envisioned this to be.  So,
actually I like it ;-).  Thanks!  I'm wondering though whether we need
the seperate dwarf2_signal_frame_sniffer.  Actually I'm sure we don't.
Targets that don't want this simply shouldn't provide the
signal_frame_p() function.  Can you fix that?  Just change
dwarf2_frame_sniffer such that it checks signal_frame_p() and returns
&dwarf2_sigtramp_frame_unwind instead of &dwarf2_frame_unwind if it's
true.

Oh, and please check the dwarf2-frame.* changes in as a seperately
from the vsyscall changes.

Cheers,

Mark

Re: [rfa] Attach vsyscall support for GNU/Linux

[Daniel Jacobowitz]

On Sun, Nov 07, 2004 at 06:35:44PM +0100, Mark Kettenis wrote:
>    Date: Fri, 5 Nov 2004 18:42:30 -0500
>    From: Daniel Jacobowitz <drow@false.org>
> 
>    How about this, in the meantime?  If you don't like the approach, I'll
>    wait until we can properly decide the relationship between unwinders
>    and frame types.
> 
>    This patch adds a new sniffer, dwarf2_signal_frame_sniffer, which will
>    only accept the frame if an architecture-specific hook has claimed that
>    this is a signal frame (i386 GNU/Linux provides one that works by
>    name).  However, we then use the CFI normally - the only difference is
>    that the result has SIGTRAMP_FRAME as its type.  It works beautifully! 
>    Tested on i386-pc-linux-gnu, with vsyscall DSO.
> 
> Within the current framework this seems to be a reasonable approach.
> Actually it's a lot less invasive than I envisioned this to be.  So,
> actually I like it ;-).  Thanks!  I'm wondering though whether we need
> the seperate dwarf2_signal_frame_sniffer.  Actually I'm sure we don't.
> Targets that don't want this simply shouldn't provide the
> signal_frame_p() function.  Can you fix that?  Just change
> dwarf2_frame_sniffer such that it checks signal_frame_p() and returns
> &dwarf2_sigtramp_frame_unwind instead of &dwarf2_frame_unwind if it's
> true.
> 
> Oh, and please check the dwarf2-frame.* changes in as a seperately
> from the vsyscall changes.

Here's this bit, as committed - let me know if I didn't get it quite
the way you wanted.  Thanks for the observation about just using one
sniffer; it looks much cleaner now.

-- 
Daniel Jacobowitz

2004-11-07  Daniel Jacobowitz  <dan@debian.org>

	* dwarf2-frame.c (struct dwarf2_frame_ops): Add signal_frame_p.
	(dwarf2_frame_set_signal_frame_p, dwarf2_frame_signal_frame_p)
	(dwarf2_signal_frame_unwind): New.
	(dwarf2_frame_sniffer): Use dwarf2_frame_signal_frame_p.
	* dwarf2-frame.h (dwarf2_frame_set_signal_frame_p): New prototype.

Index: gdb/dwarf2-frame.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/dwarf2-frame.c,v
retrieving revision 1.41
diff -u -p -r1.41 dwarf2-frame.c
--- gdb/dwarf2-frame.c	4 Nov 2004 21:15:15 -0000	1.41
+++ gdb/dwarf2-frame.c	7 Nov 2004 17:41:58 -0000
@@ -471,6 +471,10 @@ struct dwarf2_frame_ops
 {
   /* Pre-initialize the register state REG for register REGNUM.  */
   void (*init_reg) (struct gdbarch *, int, struct dwarf2_frame_state_reg *);
+
+  /* Check whether the frame preceding NEXT_FRAME will be a signal
+     trampoline.  */
+  int (*signal_frame_p) (struct gdbarch *, struct frame_info *);
 };
 
 /* Default architecture-specific register state initialization
@@ -547,6 +551,33 @@ dwarf2_frame_init_reg (struct gdbarch *g
 
   ops->init_reg (gdbarch, regnum, reg);
 }
+
+/* Set the architecture-specific signal trampoline recognition
+   function for GDBARCH to SIGNAL_FRAME_P.  */
+
+void
+dwarf2_frame_set_signal_frame_p (struct gdbarch *gdbarch,
+				 int (*signal_frame_p) (struct gdbarch *,
+							struct frame_info *))
+{
+  struct dwarf2_frame_ops *ops = gdbarch_data (gdbarch, dwarf2_frame_data);
+
+  ops->signal_frame_p = signal_frame_p;
+}
+
+/* Query the architecture-specific signal frame recognizer for
+   NEXT_FRAME.  */
+
+static int
+dwarf2_frame_signal_frame_p (struct gdbarch *gdbarch,
+			     struct frame_info *next_frame)
+{
+  struct dwarf2_frame_ops *ops = gdbarch_data (gdbarch, dwarf2_frame_data);
+
+  if (ops->signal_frame_p == NULL)
+    return 0;
+  return ops->signal_frame_p (gdbarch, next_frame);
+}
 \f
 
 struct dwarf2_frame_cache
@@ -841,6 +872,13 @@ static const struct frame_unwind dwarf2_
   dwarf2_frame_prev_register
 };
 
+static const struct frame_unwind dwarf2_signal_frame_unwind =
+{
+  SIGTRAMP_FRAME,
+  dwarf2_frame_this_id,
+  dwarf2_frame_prev_register
+};
+
 const struct frame_unwind *
 dwarf2_frame_sniffer (struct frame_info *next_frame)
 {
@@ -848,10 +886,18 @@ dwarf2_frame_sniffer (struct frame_info 
      function.  frame_pc_unwind(), for a no-return next function, can
      end up returning something past the end of this function's body.  */
   CORE_ADDR block_addr = frame_unwind_address_in_block (next_frame);
-  if (dwarf2_frame_find_fde (&block_addr))
-    return &dwarf2_frame_unwind;
+  if (!dwarf2_frame_find_fde (&block_addr))
+    return NULL;
 
-  return NULL;
+  /* On some targets, signal trampolines may have unwind information.
+     We need to recognize them so that we set the frame type
+     correctly.  */
+
+  if (dwarf2_frame_signal_frame_p (get_frame_arch (next_frame),
+				   next_frame))
+    return &dwarf2_signal_frame_unwind;
+
+  return &dwarf2_frame_unwind;
 }
 \f
 
Index: gdb/dwarf2-frame.h
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/dwarf2-frame.h,v
retrieving revision 1.6
diff -u -p -r1.6 dwarf2-frame.h
--- gdb/dwarf2-frame.h	28 Feb 2004 16:59:32 -0000	1.6
+++ gdb/dwarf2-frame.h	7 Nov 2004 17:40:41 -0000
@@ -79,6 +79,14 @@ extern void dwarf2_frame_set_init_reg (s
 				       void (*init_reg) (struct gdbarch *, int,
 					     struct dwarf2_frame_state_reg *));
 
+/* Set the architecture-specific signal trampoline recognition
+   function for GDBARCH to SIGNAL_FRAME_P.  */
+
+extern void
+  dwarf2_frame_set_signal_frame_p (struct gdbarch *gdbarch,
+				   int (*signal_frame_p) (struct gdbarch *,
+							  struct frame_info *));
+
 /* Return the frame unwind methods for the function that contains PC,
    or NULL if it can't be handled by DWARF CFI frame unwinder.  */
 

Re: [rfa] Attach vsyscall support for GNU/Linux

[Mark Kettenis]

   Date: Sun, 7 Nov 2004 16:18:43 -0500
   From: Daniel Jacobowitz <drow@false.org>

   Here's this bit, as committed - let me know if I didn't get it quite
   the way you wanted.  Thanks for the observation about just using one
   sniffer; it looks much cleaner now.

That's exactly what I meant.  Thanks!

Please go ahead and commit the other bit too.

Cheers,

Mark

Re: [rfa] Attach vsyscall support for GNU/Linux

[Daniel Jacobowitz]

On Tue, Nov 02, 2004 at 09:28:27AM -0500, Andrew Cagney wrote:
> Can you translate the above into code?  At present it's i386 so what 
> would I care?

I've checked in this patch after testing on i386-pc-linux-gnu. 
Vsyscall support now works on HEAD.

It's been a while since you wrote this, and we're much closer to the
planned release of 6.3.  I can move both patches to the branch or hold
them for 6.3.1/6.4; let me know what you'd prefer.

-- 
Daniel Jacobowitz

2004-11-07  Andrew Cagney  <cagney@redhat.com>
	    Daniel Jacobowitz  <dan@debian.org>
	    Roland McGrath  <roland@redhat.com>

	* Makefile.in (symfile-mem.o): Update dependencies.
	* i386-linux-tdep.c (i386_linux_dwarf_signal_frame_p): New.
	(i386_linux_init_abi): Call dwarf2_frame_set_signal_frame_p.
	* inf-ptrace.c (inf_ptrace_attach): Call
	observer_notify_inferior_created.
	* inftarg.c (child_attach): Likewise.
	* symfile-mem.c: Include "observer.h", "auxv.h", and "elf/common.h".
	(symbol_file_add_from_memory): Take NAME argument.  Use it for
	the new BFD's filename.
	(add_symbol_file_from_memory_command): Update call to
	symbol_file_add_from_memory.
	(struct symbol_file_add_from_memory_args, add_vsyscall_page)
	(symbol_file_add_from_memory_wrapper): New.
	(_initialize_symfile_mem): Register add_vsyscall_page as an
	inferior_created observer.

Index: gdb/Makefile.in
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/Makefile.in,v
retrieving revision 1.655
diff -u -p -r1.655 Makefile.in
--- gdb/Makefile.in	6 Nov 2004 17:18:10 -0000	1.655
+++ gdb/Makefile.in	7 Nov 2004 17:46:17 -0000
@@ -2619,7 +2619,8 @@ symfile.o: symfile.c $(defs_h) $(bfdlink
 	$(hashtab_h) $(readline_h) $(gdb_assert_h) $(block_h) \
 	$(gdb_string_h) $(gdb_stat_h)
 symfile-mem.o: symfile-mem.c $(defs_h) $(symtab_h) $(gdbcore_h) \
-	$(objfiles_h) $(gdbcmd_h) $(target_h) $(value_h) $(symfile_h)
+	$(objfiles_h) $(gdbcmd_h) $(target_h) $(value_h) $(symfile_h) \
+	$(observer_h) $(auxv_h) $(elf_common_h)
 symmisc.o: symmisc.c $(defs_h) $(symtab_h) $(gdbtypes_h) $(bfd_h) \
 	$(symfile_h) $(objfiles_h) $(breakpoint_h) $(command_h) \
 	$(gdb_obstack_h) $(language_h) $(bcache_h) $(block_h) $(gdb_regex_h) \
Index: gdb/i386-linux-tdep.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/i386-linux-tdep.c,v
retrieving revision 1.41
diff -u -p -r1.41 i386-linux-tdep.c
--- gdb/i386-linux-tdep.c	6 Aug 2004 20:58:28 -0000	1.41
+++ gdb/i386-linux-tdep.c	5 Nov 2004 20:24:29 -0000
@@ -244,6 +244,27 @@ i386_linux_sigtramp_p (struct frame_info
 	  || strcmp ("__restore_rt", name) == 0);
 }
 
+/* Return one if the unwound PC from NEXT_FRAME is in a signal trampoline
+   which may have DWARF-2 CFI.  */
+
+static int
+i386_linux_dwarf_signal_frame_p (struct gdbarch *gdbarch,
+				 struct frame_info *next_frame)
+{
+  CORE_ADDR pc = frame_pc_unwind (next_frame);
+  char *name;
+
+  find_pc_partial_function (pc, &name, NULL, NULL);
+
+  /* If a vsyscall DSO is in use, the signal trampolines may have these
+     names.  */
+  if (name && (strcmp (name, "__kernel_sigreturn") == 0
+	       || strcmp (name, "__kernel_rt_sigreturn") == 0))
+    return 1;
+
+  return 0;
+}
+
 /* Offset to struct sigcontext in ucontext, from <asm/ucontext.h>.  */
 #define I386_LINUX_UCONTEXT_SIGCONTEXT_OFFSET 20
 
@@ -414,6 +435,8 @@ i386_linux_init_abi (struct gdbarch_info
 
   /* GNU/Linux uses the dynamic linker included in the GNU C Library.  */
   set_gdbarch_skip_solib_resolver (gdbarch, glibc_skip_solib_resolver);
+
+  dwarf2_frame_set_signal_frame_p (gdbarch, i386_linux_dwarf_signal_frame_p);
 }
 
 /* Provide a prototype to silence -Wmissing-prototypes.  */
Index: gdb/inf-ptrace.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/inf-ptrace.c,v
retrieving revision 1.11
diff -u -p -r1.11 inf-ptrace.c
--- gdb/inf-ptrace.c	15 Oct 2004 13:29:33 -0000	1.11
+++ gdb/inf-ptrace.c	5 Nov 2004 20:10:05 -0000
@@ -220,6 +220,10 @@ inf_ptrace_attach (char *args, int from_
 
   inferior_ptid = pid_to_ptid (pid);
   push_target (ptrace_ops_hack);
+
+  /* Do this first, before anything has had a chance to query the
+     inferior's symbol table or similar.  */
+  observer_notify_inferior_created (&current_target, from_tty);
 }
 
 static void
Index: gdb/inftarg.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/inftarg.c,v
retrieving revision 1.34
diff -u -p -r1.34 inftarg.c
--- gdb/inftarg.c	8 Oct 2004 20:29:47 -0000	1.34
+++ gdb/inftarg.c	5 Nov 2004 20:10:05 -0000
@@ -211,6 +211,10 @@ child_attach (char *args, int from_tty)
   
   inferior_ptid = pid_to_ptid (pid);
   push_target (&deprecated_child_ops);
+
+  /* Do this first, before anything has had a chance to query the
+     inferior's symbol table or similar.  */
+  observer_notify_inferior_created (&current_target, from_tty);
 }
 
 #if !defined(CHILD_POST_ATTACH)
Index: gdb/symfile-mem.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/symfile-mem.c,v
retrieving revision 1.3
diff -u -p -r1.3 symfile-mem.c
--- gdb/symfile-mem.c	17 Jul 2004 14:24:07 -0000	1.3
+++ gdb/symfile-mem.c	7 Nov 2004 17:43:57 -0000
@@ -52,13 +52,19 @@
 #include "target.h"
 #include "value.h"
 #include "symfile.h"
+#include "observer.h"
+#include "auxv.h"
+#include "elf/common.h"
 
 
 /* Read inferior memory at ADDR to find the header of a loaded object file
    and read its in-core symbols out of inferior memory.  TEMPL is a bfd
-   representing the target's format.  */
+   representing the target's format.  NAME is the name to use for this
+   symbol file in messages; it can be NULL or a malloc-allocated string
+   which will be attached to the BFD.  */
 static struct objfile *
-symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr, int from_tty)
+symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr, char *name,
+			     int from_tty)
 {
   struct objfile *objf;
   struct bfd *nbfd;
@@ -75,7 +81,10 @@ symbol_file_add_from_memory (struct bfd 
   if (nbfd == NULL)
     error ("Failed to read a valid object file image from memory.");
 
-  nbfd->filename = xstrdup ("shared object read from target memory");
+  if (name == NULL)
+    nbfd->filename = xstrdup ("shared object read from target memory");
+  else
+    nbfd->filename = name;
 
   if (!bfd_check_format (nbfd, bfd_object))
     {
@@ -129,7 +138,73 @@ add_symbol_file_from_memory_command (cha
     error ("\
 Must use symbol-file or exec-file before add-symbol-file-from-memory.");
 
-  symbol_file_add_from_memory (templ, addr, from_tty);
+  symbol_file_add_from_memory (templ, addr, NULL, from_tty);
+}
+
+/* Arguments for symbol_file_add_from_memory_wrapper.  */
+
+struct symbol_file_add_from_memory_args
+{
+  struct bfd *bfd;
+  CORE_ADDR sysinfo_ehdr;
+  char *name;
+  int from_tty;
+};
+
+/* Wrapper function for symbol_file_add_from_memory, for
+   catch_exceptions.  */
+
+static int
+symbol_file_add_from_memory_wrapper (struct ui_out *uiout, void *data)
+{
+  struct symbol_file_add_from_memory_args *args = data;
+
+  symbol_file_add_from_memory (args->bfd, args->sysinfo_ehdr, args->name,
+			       args->from_tty);
+  return 0;
+}
+
+/* Try to add the symbols for the vsyscall page, if there is one.  This function
+   is called via the inferior_created observer.  */
+
+static void
+add_vsyscall_page (struct target_ops *target, int from_tty)
+{
+  CORE_ADDR sysinfo_ehdr;
+
+  if (target_auxv_search (target, AT_SYSINFO_EHDR, &sysinfo_ehdr) > 0
+      && sysinfo_ehdr != (CORE_ADDR) 0)
+    {
+      struct bfd *bfd;
+      struct symbol_file_add_from_memory_args args;
+
+      if (core_bfd != NULL)
+	bfd = core_bfd;
+      else if (exec_bfd != NULL)
+	bfd = exec_bfd;
+      else
+       /* FIXME: cagney/2004-05-06: Should not require an existing
+	  BFD when trying to create a run-time BFD of the VSYSCALL
+	  page in the inferior.  Unfortunately that's the current
+	  interface so for the moment bail.  Introducing a
+	  ``bfd_runtime'' (a BFD created using the loaded image) file
+	  format should fix this.  */
+	{
+	  warning ("could not load vsyscall page because no executable was specified");
+	  warning ("try using the \"file\" command first");
+	  return;
+	}
+      args.bfd = bfd;
+      args.sysinfo_ehdr = sysinfo_ehdr;
+      xasprintf (&args.name, "system-supplied DSO at 0x%s",
+		 paddr_nz (sysinfo_ehdr));
+      /* Pass zero for FROM_TTY, because the action of loading the
+	 vsyscall DSO was not triggered by the user, even if the user
+	 typed "run" at the TTY.  */
+      args.from_tty = 0;
+      catch_exceptions (uiout, symbol_file_add_from_memory_wrapper,
+			&args, NULL, RETURN_MASK_ALL);
+    }
 }
 
 \f
@@ -143,4 +218,7 @@ Load the symbols out of memory from a dy
 Give an expression for the address of the file's shared object file header.",
            &cmdlist);
 
+  /* Want to know of each new inferior so that its vsyscall info can
+     be extracted.  */
+  observer_attach_inferior_created (add_vsyscall_page);
 }

Re: [rfa] Attach vsyscall support for GNU/Linux

[Andrew Cagney]

Daniel Jacobowitz wrote:
> On Tue, Nov 02, 2004 at 09:28:27AM -0500, Andrew Cagney wrote:
> 
>>Can you translate the above into code?  At present it's i386 so what 
>>would I care?
> 
> 
> I've checked in this patch after testing on i386-pc-linux-gnu. 
> Vsyscall support now works on HEAD.
> 
> It's been a while since you wrote this, and we're much closer to the
> planned release of 6.3.  I can move both patches to the branch or hold
> them for 6.3.1/6.4; let me know what you'd prefer.

Hold them for 6.3.1 (in a few weeks), we're not so much closer as on top 
of 6.3.

Andrew