[rfa:NetBSD/ppc] Implement signal trampoline unwinder

[rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

It appears to work (but doesn't have much effect without an rs6000 
unwinder).

One question (and to follow up my earlier post) is there a better way of 
doing this:

+  if (frame_pc_unwind (next_frame) > 0x7f000000)
+    /* Assume anything that is vaguely on the stack is a signal
+       trampoline.  */
+    return &ppcnbsd_sigtramp_unwind;

ok?, eventually for 6.1?

Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3939 bytes --]

2004-02-29  Andrew Cagney  <cagney@redhat.com>

	* ppcnbsd-tdep.c: Include "trad-frame.h", and "frame-unwind.h".
	(struct ppcnbsd_sigtramp_cache, ppcnbsd_sigtramp_this_id)
	(ppcnbsd_sigtramp_prev_register, ppcnbsd_sigtramp_cache)
	(ppcnbsd_sigtramp_sniffer, ppcnbsd_sigtramp_unwind)
	(ppcnbsd_init_abi): Implement a NetBSD/PPC signal trampline
	unwinder, register.

Index: ppcnbsd-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ppcnbsd-tdep.c,v
retrieving revision 1.11
diff -u -r1.11 ppcnbsd-tdep.c
--- ppcnbsd-tdep.c	10 Nov 2003 22:47:28 -0000	1.11
+++ ppcnbsd-tdep.c	1 Mar 2004 00:58:20 -0000
@@ -26,6 +26,8 @@
 #include "breakpoint.h"
 #include "value.h"
 #include "osabi.h"
+#include "trad-frame.h"
+#include "frame-unwind.h"
 
 #include "ppc-tdep.h"
 #include "ppcnbsd-tdep.h"
@@ -227,6 +229,89 @@
 					     readbuf, writebuf);
 }
 
+struct ppcnbsd_sigtramp_cache
+{
+  CORE_ADDR base;
+  struct trad_frame_saved_reg *saved_regs;
+};
+
+static struct ppcnbsd_sigtramp_cache *
+ppcnbsd_sigtramp_cache (struct frame_info *next_frame, void **this_cache)
+{
+  CORE_ADDR offset;
+  int i;
+  struct ppcnbsd_sigtramp_cache *cache;
+  struct gdbarch *gdbarch = get_frame_arch (next_frame);
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+  if ((*this_cache) != NULL)
+    return (*this_cache);
+  cache = FRAME_OBSTACK_ZALLOC (struct ppcnbsd_sigtramp_cache);
+  (*this_cache) = cache;
+  cache->saved_regs = trad_frame_alloc_saved_regs (next_frame);
+
+  cache->base = frame_unwind_register_unsigned (next_frame, SP_REGNUM);
+  offset = cache->base + 0x18 + 2 * tdep->wordsize;
+  for (i = 0; i < 32; i++)
+    {
+      int regnum = i + tdep->ppc_gp0_regnum;
+      cache->saved_regs[regnum].addr = offset;
+      offset += tdep->wordsize;
+    }
+  cache->saved_regs[tdep->ppc_lr_regnum].addr = offset;
+  offset += tdep->wordsize;
+  cache->saved_regs[tdep->ppc_cr_regnum].addr = offset;
+  offset += tdep->wordsize;
+  cache->saved_regs[tdep->ppc_xer_regnum].addr = offset;
+  offset += tdep->wordsize;
+  cache->saved_regs[tdep->ppc_ctr_regnum].addr = offset;
+  offset += tdep->wordsize;
+  cache->saved_regs[PC_REGNUM].addr = offset; /* SRR0? */
+  offset += tdep->wordsize;
+  return cache;
+}
+
+static void
+ppcnbsd_sigtramp_this_id (struct frame_info *next_frame, void **this_cache,
+			  struct frame_id *this_id)
+{
+  struct ppcnbsd_sigtramp_cache *info = ppcnbsd_sigtramp_cache (next_frame,
+								this_cache);
+  (*this_id) = frame_id_build (info->base, frame_pc_unwind (next_frame));
+}
+
+static void
+ppcnbsd_sigtramp_prev_register (struct frame_info *next_frame,
+				void **this_cache,
+				int regnum, int *optimizedp,
+				enum lval_type *lvalp, CORE_ADDR *addrp,
+				int *realnump, void *valuep)
+{
+  struct ppcnbsd_sigtramp_cache *info = ppcnbsd_sigtramp_cache (next_frame,
+								this_cache);
+  trad_frame_prev_register (next_frame, info->saved_regs, regnum,
+			    optimizedp, lvalp, addrp, realnump, valuep);
+}
+
+static const struct frame_unwind ppcnbsd_sigtramp_unwind =
+{
+  SIGTRAMP_FRAME,
+  ppcnbsd_sigtramp_this_id,
+  ppcnbsd_sigtramp_prev_register
+};
+
+static const struct frame_unwind *
+ppcnbsd_sigtramp_sniffer (struct frame_info *next_frame)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (get_frame_arch (next_frame));
+  if (frame_pc_unwind (next_frame) > 0x7f000000)
+    /* Assume anything that is vaguely on the stack is a signal
+       trampoline.  */
+    return &ppcnbsd_sigtramp_unwind;
+  else
+    return NULL;
+}
+
 static void
 ppcnbsd_init_abi (struct gdbarch_info info,
                   struct gdbarch *gdbarch)
@@ -237,6 +322,7 @@
   set_gdbarch_return_value (gdbarch, ppcnbsd_return_value);
   set_solib_svr4_fetch_link_map_offsets (gdbarch,
                                 nbsd_ilp32_solib_svr4_fetch_link_map_offsets);
+  frame_unwind_append_sniffer (gdbarch, ppcnbsd_sigtramp_sniffer);
 }
 
 void

[rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

It appears to work (but doesn't have much effect without an rs6000 
unwinder).

One question (and to follow up my earlier post) is there a better way of 
doing this:

+  if (frame_pc_unwind (next_frame) > 0x7f000000)
+    /* Assume anything that is vaguely on the stack is a signal
+       trampoline.  */
+    return &ppcnbsd_sigtramp_unwind;

ok?, eventually for 6.1?

Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3939 bytes --]

2004-02-29  Andrew Cagney  <cagney@redhat.com>

	* ppcnbsd-tdep.c: Include "trad-frame.h", and "frame-unwind.h".
	(struct ppcnbsd_sigtramp_cache, ppcnbsd_sigtramp_this_id)
	(ppcnbsd_sigtramp_prev_register, ppcnbsd_sigtramp_cache)
	(ppcnbsd_sigtramp_sniffer, ppcnbsd_sigtramp_unwind)
	(ppcnbsd_init_abi): Implement a NetBSD/PPC signal trampline
	unwinder, register.

Index: ppcnbsd-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ppcnbsd-tdep.c,v
retrieving revision 1.11
diff -u -r1.11 ppcnbsd-tdep.c
--- ppcnbsd-tdep.c	10 Nov 2003 22:47:28 -0000	1.11
+++ ppcnbsd-tdep.c	1 Mar 2004 00:58:20 -0000
@@ -26,6 +26,8 @@
 #include "breakpoint.h"
 #include "value.h"
 #include "osabi.h"
+#include "trad-frame.h"
+#include "frame-unwind.h"
 
 #include "ppc-tdep.h"
 #include "ppcnbsd-tdep.h"
@@ -227,6 +229,89 @@
 					     readbuf, writebuf);
 }
 
+struct ppcnbsd_sigtramp_cache
+{
+  CORE_ADDR base;
+  struct trad_frame_saved_reg *saved_regs;
+};
+
+static struct ppcnbsd_sigtramp_cache *
+ppcnbsd_sigtramp_cache (struct frame_info *next_frame, void **this_cache)
+{
+  CORE_ADDR offset;
+  int i;
+  struct ppcnbsd_sigtramp_cache *cache;
+  struct gdbarch *gdbarch = get_frame_arch (next_frame);
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+  if ((*this_cache) != NULL)
+    return (*this_cache);
+  cache = FRAME_OBSTACK_ZALLOC (struct ppcnbsd_sigtramp_cache);
+  (*this_cache) = cache;
+  cache->saved_regs = trad_frame_alloc_saved_regs (next_frame);
+
+  cache->base = frame_unwind_register_unsigned (next_frame, SP_REGNUM);
+  offset = cache->base + 0x18 + 2 * tdep->wordsize;
+  for (i = 0; i < 32; i++)
+    {
+      int regnum = i + tdep->ppc_gp0_regnum;
+      cache->saved_regs[regnum].addr = offset;
+      offset += tdep->wordsize;
+    }
+  cache->saved_regs[tdep->ppc_lr_regnum].addr = offset;
+  offset += tdep->wordsize;
+  cache->saved_regs[tdep->ppc_cr_regnum].addr = offset;
+  offset += tdep->wordsize;
+  cache->saved_regs[tdep->ppc_xer_regnum].addr = offset;
+  offset += tdep->wordsize;
+  cache->saved_regs[tdep->ppc_ctr_regnum].addr = offset;
+  offset += tdep->wordsize;
+  cache->saved_regs[PC_REGNUM].addr = offset; /* SRR0? */
+  offset += tdep->wordsize;
+  return cache;
+}
+
+static void
+ppcnbsd_sigtramp_this_id (struct frame_info *next_frame, void **this_cache,
+			  struct frame_id *this_id)
+{
+  struct ppcnbsd_sigtramp_cache *info = ppcnbsd_sigtramp_cache (next_frame,
+								this_cache);
+  (*this_id) = frame_id_build (info->base, frame_pc_unwind (next_frame));
+}
+
+static void
+ppcnbsd_sigtramp_prev_register (struct frame_info *next_frame,
+				void **this_cache,
+				int regnum, int *optimizedp,
+				enum lval_type *lvalp, CORE_ADDR *addrp,
+				int *realnump, void *valuep)
+{
+  struct ppcnbsd_sigtramp_cache *info = ppcnbsd_sigtramp_cache (next_frame,
+								this_cache);
+  trad_frame_prev_register (next_frame, info->saved_regs, regnum,
+			    optimizedp, lvalp, addrp, realnump, valuep);
+}
+
+static const struct frame_unwind ppcnbsd_sigtramp_unwind =
+{
+  SIGTRAMP_FRAME,
+  ppcnbsd_sigtramp_this_id,
+  ppcnbsd_sigtramp_prev_register
+};
+
+static const struct frame_unwind *
+ppcnbsd_sigtramp_sniffer (struct frame_info *next_frame)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (get_frame_arch (next_frame));
+  if (frame_pc_unwind (next_frame) > 0x7f000000)
+    /* Assume anything that is vaguely on the stack is a signal
+       trampoline.  */
+    return &ppcnbsd_sigtramp_unwind;
+  else
+    return NULL;
+}
+
 static void
 ppcnbsd_init_abi (struct gdbarch_info info,
                   struct gdbarch *gdbarch)
@@ -237,6 +322,7 @@
   set_gdbarch_return_value (gdbarch, ppcnbsd_return_value);
   set_solib_svr4_fetch_link_map_offsets (gdbarch,
                                 nbsd_ilp32_solib_svr4_fetch_link_map_offsets);
+  frame_unwind_append_sniffer (gdbarch, ppcnbsd_sigtramp_sniffer);
 }
 
 void

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Daniel Jacobowitz]

On Sun, Feb 29, 2004 at 08:05:28PM -0500, Andrew Cagney wrote:
> It appears to work (but doesn't have much effect without an rs6000 
> unwinder).
> 
> One question (and to follow up my earlier post) is there a better way of 
> doing this:
> 
> +  if (frame_pc_unwind (next_frame) > 0x7f000000)
> +    /* Assume anything that is vaguely on the stack is a signal
> +       trampoline.  */
> +    return &ppcnbsd_sigtramp_unwind;
> 
> ok?, eventually for 6.1?

For other targets, we grub in the code for the sigtramp instruction
sequence.  I'm betting it's fixed for NetBSD too?  ppc_linux_in_sigtramp
does this.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Andrew Cagney]

> On Sun, Feb 29, 2004 at 08:05:28PM -0500, Andrew Cagney wrote:
> 
>>> It appears to work (but doesn't have much effect without an rs6000 
>>> unwinder).
>>> 
>>> One question (and to follow up my earlier post) is there a better way of 
>>> doing this:
>>> 
>>> +  if (frame_pc_unwind (next_frame) > 0x7f000000)
>>> +    /* Assume anything that is vaguely on the stack is a signal
>>> +       trampoline.  */
>>> +    return &ppcnbsd_sigtramp_unwind;
>>> 
>>> ok?, eventually for 6.1?
> 
> 
> For other targets, we grub in the code for the sigtramp instruction
> sequence.  I'm betting it's fixed for NetBSD too?  ppc_linux_in_sigtramp
> does this.

That's potentially expensive - there should also be a predicate like the 
above before the stack is read checked.

Andrew

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Andrew Cagney]

> On Sun, Feb 29, 2004 at 08:05:28PM -0500, Andrew Cagney wrote:
> 
>>> It appears to work (but doesn't have much effect without an rs6000 
>>> unwinder).
>>> 
>>> One question (and to follow up my earlier post) is there a better way of 
>>> doing this:
>>> 
>>> +  if (frame_pc_unwind (next_frame) > 0x7f000000)
>>> +    /* Assume anything that is vaguely on the stack is a signal
>>> +       trampoline.  */
>>> +    return &ppcnbsd_sigtramp_unwind;
>>> 
>>> ok?, eventually for 6.1?
> 
> 
> For other targets, we grub in the code for the sigtramp instruction
> sequence.  I'm betting it's fixed for NetBSD too?  ppc_linux_in_sigtramp
> does this.

That's potentially expensive - there should also be a predicate like the 
above before the stack is read checked.

Andrew

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Daniel Jacobowitz]

On Sun, Feb 29, 2004 at 08:33:11PM -0500, Andrew Cagney wrote:
> >On Sun, Feb 29, 2004 at 08:05:28PM -0500, Andrew Cagney wrote:
> >
> >>>It appears to work (but doesn't have much effect without an rs6000 
> >>>unwinder).
> >>>
> >>>One question (and to follow up my earlier post) is there a better way of 
> >>>doing this:
> >>>
> >>>+  if (frame_pc_unwind (next_frame) > 0x7f000000)
> >>>+    /* Assume anything that is vaguely on the stack is a signal
> >>>+       trampoline.  */
> >>>+    return &ppcnbsd_sigtramp_unwind;
> >>>
> >>>ok?, eventually for 6.1?
> >
> >
> >For other targets, we grub in the code for the sigtramp instruction
> >sequence.  I'm betting it's fixed for NetBSD too?  ppc_linux_in_sigtramp
> >does this.
> 
> That's potentially expensive - there should also be a predicate like the 
> above before the stack is read checked.

Then you risk both sigaltstack and thread support.  Thread stacks can
end up literally anywhere - and do!

It might be possible to compare to the current stack pointer, if you're
convinced the sigreturn sequence will remain on the stack.  I don't
know anything about NetBSD - for e.g. i386 GNU/Linux, this isn't
necessarily true, but that's handled specially.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Mark Kettenis]

   Date: Sun, 29 Feb 2004 21:47:11 -0500
   From: Daniel Jacobowitz <drow@false.org>

   On Sun, Feb 29, 2004 at 08:33:11PM -0500, Andrew Cagney wrote:
   > >On Sun, Feb 29, 2004 at 08:05:28PM -0500, Andrew Cagney wrote:
   > >
   > >>>It appears to work (but doesn't have much effect without an rs6000 
   > >>>unwinder).
   > >>>
   > >>>One question (and to follow up my earlier post) is there a better way of 
   > >>>doing this:
   > >>>
   > >>>+  if (frame_pc_unwind (next_frame) > 0x7f000000)
   > >>>+    /* Assume anything that is vaguely on the stack is a signal
   > >>>+       trampoline.  */
   > >>>+    return &ppcnbsd_sigtramp_unwind;
   > >>>
   > >>>ok?, eventually for 6.1?
   > >
   > >
   > >For other targets, we grub in the code for the sigtramp instruction
   > >sequence.  I'm betting it's fixed for NetBSD too?  ppc_linux_in_sigtramp
   > >does this.
   > 
   > That's potentially expensive - there should also be a predicate like the 
   > above before the stack is read checked.

   Then you risk both sigaltstack and thread support.  Thread stacks can
   end up literally anywhere - and do!

Not really.  While the signal trampoline appears to be on the stack,
it really is a specially mapped area just at the end of the userspace
VM range.  This mapping appears at the same location in all the
threads, regardless whether you use sigaltstack or not.

The problem is that the location of the signal trampoline depends on
the VM layout, which can be changed.  And on OpenBSD (which is very
similar to NetBSD in many respects) the signal trampoline is mapped at
a random location.  So checking for the address isn't the most robust
way.  That's why NetBSD/i386 doesn't do this anymore, but instead
looks for a specific instruction sequence (the instruction sequence
for the sigreturn(2) system call).

If you're going to check the instruction sequence, you can optimize
things by only doing so if NAME is NULL.

   It might be possible to compare to the current stack pointer, if you're
   convinced the sigreturn sequence will remain on the stack.  I don't
   know anything about NetBSD - for e.g. i386 GNU/Linux, this isn't
   necessarily true, but that's handled specially.

NetBSD is moving away from using kernel-provided signal trampolines.
NetBSD 2.0 will use signal trampolines provided by libc.  These
tramplones can be recognized by their name: they start with
__sigtramp.  See nbsd-tdep.c:nbsd_pc_in_sigtramp() and its usage in
amd64nbsd-tdep.c.

Mark

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Jason Thorpe]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]


On Mar 1, 2004, at 1:33 AM, Mark Kettenis wrote:

> The problem is that the location of the signal trampoline depends on
> the VM layout, which can be changed.  And on OpenBSD (which is very
> similar to NetBSD in many respects) the signal trampoline is mapped at
> a random location.  So checking for the address isn't the most robust
> way.  That's why NetBSD/i386 doesn't do this anymore, but instead
> looks for a specific instruction sequence (the instruction sequence
> for the sigreturn(2) system call).

Yes, other NetBSD targets do this as well, Alpha and MIPS, for example.

> NetBSD is moving away from using kernel-provided signal trampolines.
> NetBSD 2.0 will use signal trampolines provided by libc.  These
> tramplones can be recognized by their name: they start with
> __sigtramp.  See nbsd-tdep.c:nbsd_pc_in_sigtramp() and its usage in
> amd64nbsd-tdep.c.

Right.  They've been provided by libc for quite some time in -current, 
and 2.0 will ship with them when it ships.

In general, I think doing things in the debugger based on a priori 
knowledge of a magic address is kinda gross.

         -- Jason R. Thorpe <thorpej@wasabisystems.com>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Jason Thorpe]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]


On Mar 1, 2004, at 1:33 AM, Mark Kettenis wrote:

> The problem is that the location of the signal trampoline depends on
> the VM layout, which can be changed.  And on OpenBSD (which is very
> similar to NetBSD in many respects) the signal trampoline is mapped at
> a random location.  So checking for the address isn't the most robust
> way.  That's why NetBSD/i386 doesn't do this anymore, but instead
> looks for a specific instruction sequence (the instruction sequence
> for the sigreturn(2) system call).

Yes, other NetBSD targets do this as well, Alpha and MIPS, for example.

> NetBSD is moving away from using kernel-provided signal trampolines.
> NetBSD 2.0 will use signal trampolines provided by libc.  These
> tramplones can be recognized by their name: they start with
> __sigtramp.  See nbsd-tdep.c:nbsd_pc_in_sigtramp() and its usage in
> amd64nbsd-tdep.c.

Right.  They've been provided by libc for quite some time in -current, 
and 2.0 will ship with them when it ships.

In general, I think doing things in the debugger based on a priori 
knowledge of a magic address is kinda gross.

         -- Jason R. Thorpe <thorpej@wasabisystems.com>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Andrew Cagney]

> 
> On Mar 1, 2004, at 1:33 AM, Mark Kettenis wrote:
> 
>> The problem is that the location of the signal trampoline depends on
>> the VM layout, which can be changed.  And on OpenBSD (which is very
>> similar to NetBSD in many respects) the signal trampoline is mapped at
>> a random location.  So checking for the address isn't the most robust
>> way.  That's why NetBSD/i386 doesn't do this anymore, but instead
>> looks for a specific instruction sequence (the instruction sequence
>> for the sigreturn(2) system call).
> 
> 
> Yes, other NetBSD targets do this as well, Alpha and MIPS, for example.
> 
>> NetBSD is moving away from using kernel-provided signal trampolines.
>> NetBSD 2.0 will use signal trampolines provided by libc.  These
>> tramplones can be recognized by their name: they start with
>> __sigtramp.  See nbsd-tdep.c:nbsd_pc_in_sigtramp() and its usage in
>> amd64nbsd-tdep.c.
> 
> 
> Right.  They've been provided by libc for quite some time in -current, and 2.0 will ship with them when it ships.

Jason, am I correct to assume that the second SC here:

(gdb) x/10i $lr
0x7fffefdc:     addi    r3,r1,24
0x7fffefe0:     li      r0,295
0x7fffefe4:     sc
0x7fffefe8:     li      r0,1
0x7fffefec:     sc
0x7fffeff0:     .long 0x7fffe56c

isn't part of the sigtramp?

Andrew

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Jason Thorpe]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]


On Mar 3, 2004, at 12:43 PM, Andrew Cagney wrote:

> Jason, am I correct to assume that the second SC here:
>
> (gdb) x/10i $lr
> 0x7fffefdc:     addi    r3,r1,24
> 0x7fffefe0:     li      r0,295
> 0x7fffefe4:     sc

This is __sigreturn14

> 0x7fffefe8:     li      r0,1
> 0x7fffefec:     sc

and this is exit (process croaks if sigreturn failed).

> 0x7fffeff0:     .long 0x7fffe56c
>
> isn't part of the sigtramp?
>
> Andrew
>
>
         -- Jason R. Thorpe <thorpej@wasabisystems.com>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Mark Kettenis]

   From: Jason Thorpe <thorpej@wasabisystems.com>
   Date: Wed, 3 Mar 2004 12:46:40 -0800

   On Mar 3, 2004, at 12:43 PM, Andrew Cagney wrote:

   > Jason, am I correct to assume that the second SC here:
   >
   > (gdb) x/10i $lr
   > 0x7fffefdc:     addi    r3,r1,24
   > 0x7fffefe0:     li      r0,295
   > 0x7fffefe4:     sc

   This is __sigreturn14

   > 0x7fffefe8:     li      r0,1
   > 0x7fffefec:     sc

   and this is exit (process croaks if sigreturn failed).

Andrew, 

This is the usual pattern.  A sigreturn system call followed by an
exit system call.  There may be several versions of the sigreturn
system call in an OS (besides __sigreturn14, NetBSD also has an older
sigreturn system call).  Before the system call there may be some code
that does the call to the signal handler.  If all instructions have
the same length (as is the case on SPARC, and appears to be the case
on PPC) it may be enough to check for the sigreturn system call
(i.e. li r0,295; sc).

Mark

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Mark Kettenis]

   From: Jason Thorpe <thorpej@wasabisystems.com>
   Date: Wed, 3 Mar 2004 12:46:40 -0800

   On Mar 3, 2004, at 12:43 PM, Andrew Cagney wrote:

   > Jason, am I correct to assume that the second SC here:
   >
   > (gdb) x/10i $lr
   > 0x7fffefdc:     addi    r3,r1,24
   > 0x7fffefe0:     li      r0,295
   > 0x7fffefe4:     sc

   This is __sigreturn14

   > 0x7fffefe8:     li      r0,1
   > 0x7fffefec:     sc

   and this is exit (process croaks if sigreturn failed).

Andrew, 

This is the usual pattern.  A sigreturn system call followed by an
exit system call.  There may be several versions of the sigreturn
system call in an OS (besides __sigreturn14, NetBSD also has an older
sigreturn system call).  Before the system call there may be some code
that does the call to the signal handler.  If all instructions have
the same length (as is the case on SPARC, and appears to be the case
on PPC) it may be enough to check for the sigreturn system call
(i.e. li r0,295; sc).

Mark

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Jason Thorpe]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]


On Mar 3, 2004, at 12:43 PM, Andrew Cagney wrote:

> Jason, am I correct to assume that the second SC here:
>
> (gdb) x/10i $lr
> 0x7fffefdc:     addi    r3,r1,24
> 0x7fffefe0:     li      r0,295
> 0x7fffefe4:     sc

This is __sigreturn14

> 0x7fffefe8:     li      r0,1
> 0x7fffefec:     sc

and this is exit (process croaks if sigreturn failed).

> 0x7fffeff0:     .long 0x7fffe56c
>
> isn't part of the sigtramp?
>
> Andrew
>
>
         -- Jason R. Thorpe <thorpej@wasabisystems.com>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Andrew Cagney]

> 
> On Mar 1, 2004, at 1:33 AM, Mark Kettenis wrote:
> 
>> The problem is that the location of the signal trampoline depends on
>> the VM layout, which can be changed.  And on OpenBSD (which is very
>> similar to NetBSD in many respects) the signal trampoline is mapped at
>> a random location.  So checking for the address isn't the most robust
>> way.  That's why NetBSD/i386 doesn't do this anymore, but instead
>> looks for a specific instruction sequence (the instruction sequence
>> for the sigreturn(2) system call).
> 
> 
> Yes, other NetBSD targets do this as well, Alpha and MIPS, for example.
> 
>> NetBSD is moving away from using kernel-provided signal trampolines.
>> NetBSD 2.0 will use signal trampolines provided by libc.  These
>> tramplones can be recognized by their name: they start with
>> __sigtramp.  See nbsd-tdep.c:nbsd_pc_in_sigtramp() and its usage in
>> amd64nbsd-tdep.c.
> 
> 
> Right.  They've been provided by libc for quite some time in -current, and 2.0 will ship with them when it ships.

Jason, am I correct to assume that the second SC here:

(gdb) x/10i $lr
0x7fffefdc:     addi    r3,r1,24
0x7fffefe0:     li      r0,295
0x7fffefe4:     sc
0x7fffefe8:     li      r0,1
0x7fffefec:     sc
0x7fffeff0:     .long 0x7fffe56c

isn't part of the sigtramp?

Andrew

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Andrew Cagney]

> 
> On Mar 1, 2004, at 1:33 AM, Mark Kettenis wrote:
> 
>> The problem is that the location of the signal trampoline depends on
>> the VM layout, which can be changed.  And on OpenBSD (which is very
>> similar to NetBSD in many respects) the signal trampoline is mapped at
>> a random location.  So checking for the address isn't the most robust
>> way.  That's why NetBSD/i386 doesn't do this anymore, but instead
>> looks for a specific instruction sequence (the instruction sequence
>> for the sigreturn(2) system call).
> 
> 
> Yes, other NetBSD targets do this as well, Alpha and MIPS, for example.
> 
>> NetBSD is moving away from using kernel-provided signal trampolines.
>> NetBSD 2.0 will use signal trampolines provided by libc.  These
>> tramplones can be recognized by their name: they start with
>> __sigtramp.  See nbsd-tdep.c:nbsd_pc_in_sigtramp() and its usage in
>> amd64nbsd-tdep.c.
> 
> 
> Right.  They've been provided by libc for quite some time in -current, and 2.0 will ship with them when it ships.

So something like:

	if (have symbol)
	  {
	    return (symbol matches __sigtramp.*);
	  }
	else
	  {
	    return (mem[pc] == magic && mem[pc+1] == magic && ...);
	  }

Is it possible to add an extra guard to the else clause so that memory 
is only examined when there's a reasonable likelyhood of it being a 
sigtramp?

Andrew

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Andrew Cagney]

> 
> On Mar 1, 2004, at 1:33 AM, Mark Kettenis wrote:
> 
>> The problem is that the location of the signal trampoline depends on
>> the VM layout, which can be changed.  And on OpenBSD (which is very
>> similar to NetBSD in many respects) the signal trampoline is mapped at
>> a random location.  So checking for the address isn't the most robust
>> way.  That's why NetBSD/i386 doesn't do this anymore, but instead
>> looks for a specific instruction sequence (the instruction sequence
>> for the sigreturn(2) system call).
> 
> 
> Yes, other NetBSD targets do this as well, Alpha and MIPS, for example.
> 
>> NetBSD is moving away from using kernel-provided signal trampolines.
>> NetBSD 2.0 will use signal trampolines provided by libc.  These
>> tramplones can be recognized by their name: they start with
>> __sigtramp.  See nbsd-tdep.c:nbsd_pc_in_sigtramp() and its usage in
>> amd64nbsd-tdep.c.
> 
> 
> Right.  They've been provided by libc for quite some time in -current, and 2.0 will ship with them when it ships.

So something like:

	if (have symbol)
	  {
	    return (symbol matches __sigtramp.*);
	  }
	else
	  {
	    return (mem[pc] == magic && mem[pc+1] == magic && ...);
	  }

Is it possible to add an extra guard to the else clause so that memory 
is only examined when there's a reasonable likelyhood of it being a 
sigtramp?

Andrew

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

Draging the attached back into the thread :-)

> So something like:
> 
>     if (have symbol)
>       {
>         return (symbol matches __sigtramp.*);
>       }
>     else
>       {
>         return (mem[pc] == magic && mem[pc+1] == magic && ...);
>       }

Making it:

	if (have symbol)
		-- new code
		return symbol matches __sigtramp.*
	else if (!find_pc_section)
		-- old code, sigtramps do not exist in a section
		return (mem[pc] == magic && mem[pc+1] == magic && ...)

yes, that's much better.

> Is it possible to add an extra guard to the else clause so that memory is only examined when there's a reasonable likelyhood of it being a sigtramp?

Andrew


[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 19 bytes --]

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

Draging the attached back into the thread :-)

> So something like:
> 
>     if (have symbol)
>       {
>         return (symbol matches __sigtramp.*);
>       }
>     else
>       {
>         return (mem[pc] == magic && mem[pc+1] == magic && ...);
>       }

Making it:

	if (have symbol)
		-- new code
		return symbol matches __sigtramp.*
	else if (!find_pc_section)
		-- old code, sigtramps do not exist in a section
		return (mem[pc] == magic && mem[pc+1] == magic && ...)

yes, that's much better.

> Is it possible to add an extra guard to the else clause so that memory is only examined when there's a reasonable likelyhood of it being a sigtramp?

Andrew


[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 19 bytes --]

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Mark Kettenis]

   Date: Sun, 29 Feb 2004 21:47:11 -0500
   From: Daniel Jacobowitz <drow@false.org>

   On Sun, Feb 29, 2004 at 08:33:11PM -0500, Andrew Cagney wrote:
   > >On Sun, Feb 29, 2004 at 08:05:28PM -0500, Andrew Cagney wrote:
   > >
   > >>>It appears to work (but doesn't have much effect without an rs6000 
   > >>>unwinder).
   > >>>
   > >>>One question (and to follow up my earlier post) is there a better way of 
   > >>>doing this:
   > >>>
   > >>>+  if (frame_pc_unwind (next_frame) > 0x7f000000)
   > >>>+    /* Assume anything that is vaguely on the stack is a signal
   > >>>+       trampoline.  */
   > >>>+    return &ppcnbsd_sigtramp_unwind;
   > >>>
   > >>>ok?, eventually for 6.1?
   > >
   > >
   > >For other targets, we grub in the code for the sigtramp instruction
   > >sequence.  I'm betting it's fixed for NetBSD too?  ppc_linux_in_sigtramp
   > >does this.
   > 
   > That's potentially expensive - there should also be a predicate like the 
   > above before the stack is read checked.

   Then you risk both sigaltstack and thread support.  Thread stacks can
   end up literally anywhere - and do!

Not really.  While the signal trampoline appears to be on the stack,
it really is a specially mapped area just at the end of the userspace
VM range.  This mapping appears at the same location in all the
threads, regardless whether you use sigaltstack or not.

The problem is that the location of the signal trampoline depends on
the VM layout, which can be changed.  And on OpenBSD (which is very
similar to NetBSD in many respects) the signal trampoline is mapped at
a random location.  So checking for the address isn't the most robust
way.  That's why NetBSD/i386 doesn't do this anymore, but instead
looks for a specific instruction sequence (the instruction sequence
for the sigreturn(2) system call).

If you're going to check the instruction sequence, you can optimize
things by only doing so if NAME is NULL.

   It might be possible to compare to the current stack pointer, if you're
   convinced the sigreturn sequence will remain on the stack.  I don't
   know anything about NetBSD - for e.g. i386 GNU/Linux, this isn't
   necessarily true, but that's handled specially.

NetBSD is moving away from using kernel-provided signal trampolines.
NetBSD 2.0 will use signal trampolines provided by libc.  These
tramplones can be recognized by their name: they start with
__sigtramp.  See nbsd-tdep.c:nbsd_pc_in_sigtramp() and its usage in
amd64nbsd-tdep.c.

Mark

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Daniel Jacobowitz]

On Sun, Feb 29, 2004 at 08:33:11PM -0500, Andrew Cagney wrote:
> >On Sun, Feb 29, 2004 at 08:05:28PM -0500, Andrew Cagney wrote:
> >
> >>>It appears to work (but doesn't have much effect without an rs6000 
> >>>unwinder).
> >>>
> >>>One question (and to follow up my earlier post) is there a better way of 
> >>>doing this:
> >>>
> >>>+  if (frame_pc_unwind (next_frame) > 0x7f000000)
> >>>+    /* Assume anything that is vaguely on the stack is a signal
> >>>+       trampoline.  */
> >>>+    return &ppcnbsd_sigtramp_unwind;
> >>>
> >>>ok?, eventually for 6.1?
> >
> >
> >For other targets, we grub in the code for the sigtramp instruction
> >sequence.  I'm betting it's fixed for NetBSD too?  ppc_linux_in_sigtramp
> >does this.
> 
> That's potentially expensive - there should also be a predicate like the 
> above before the stack is read checked.

Then you risk both sigaltstack and thread support.  Thread stacks can
end up literally anywhere - and do!

It might be possible to compare to the current stack pointer, if you're
convinced the sigreturn sequence will remain on the stack.  I don't
know anything about NetBSD - for e.g. i386 GNU/Linux, this isn't
necessarily true, but that's handled specially.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Daniel Jacobowitz]

On Sun, Feb 29, 2004 at 08:05:28PM -0500, Andrew Cagney wrote:
> It appears to work (but doesn't have much effect without an rs6000 
> unwinder).
> 
> One question (and to follow up my earlier post) is there a better way of 
> doing this:
> 
> +  if (frame_pc_unwind (next_frame) > 0x7f000000)
> +    /* Assume anything that is vaguely on the stack is a signal
> +       trampoline.  */
> +    return &ppcnbsd_sigtramp_unwind;
> 
> ok?, eventually for 6.1?

For other targets, we grub in the code for the sigtramp instruction
sequence.  I'm betting it's fixed for NetBSD too?  ppc_linux_in_sigtramp
does this.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Kevin Buettner]

On Sun, 29 Feb 2004 20:05:28 -0500
Andrew Cagney <cagney@gnu.org> wrote:

>	* ppcnbsd-tdep.c: Include "trad-frame.h", and "frame-unwind.h".
>	(struct ppcnbsd_sigtramp_cache, ppcnbsd_sigtramp_this_id)
>	(ppcnbsd_sigtramp_prev_register, ppcnbsd_sigtramp_cache)
>	(ppcnbsd_sigtramp_sniffer, ppcnbsd_sigtramp_unwind)
>	(ppcnbsd_init_abi): Implement a NetBSD/PPC signal trampline
>	unwinder, register.

After reading the disucssion, the only part about this which bothers
me is the part that you yourself had a question about:

> +  if (frame_pc_unwind (next_frame) > 0x7f000000)
> +    /* Assume anything that is vaguely on the stack is a signal
> +       trampoline.  */
> +    return &ppcnbsd_sigtramp_unwind;

Given Mark K's comments, I think it would be better to check for a
specific instruction sequence.  I know it's expensive, but it seems
like a more robust approach.  (But, also given Mark K's comments,
it seems that a name based approach will work well in the future.)

Kevin

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Kevin Buettner]

On Sun, 29 Feb 2004 20:05:28 -0500
Andrew Cagney <cagney@gnu.org> wrote:

>	* ppcnbsd-tdep.c: Include "trad-frame.h", and "frame-unwind.h".
>	(struct ppcnbsd_sigtramp_cache, ppcnbsd_sigtramp_this_id)
>	(ppcnbsd_sigtramp_prev_register, ppcnbsd_sigtramp_cache)
>	(ppcnbsd_sigtramp_sniffer, ppcnbsd_sigtramp_unwind)
>	(ppcnbsd_init_abi): Implement a NetBSD/PPC signal trampline
>	unwinder, register.

After reading the disucssion, the only part about this which bothers
me is the part that you yourself had a question about:

> +  if (frame_pc_unwind (next_frame) > 0x7f000000)
> +    /* Assume anything that is vaguely on the stack is a signal
> +       trampoline.  */
> +    return &ppcnbsd_sigtramp_unwind;

Given Mark K's comments, I think it would be better to check for a
specific instruction sequence.  I know it's expensive, but it seems
like a more robust approach.  (But, also given Mark K's comments,
it seems that a name based approach will work well in the future.)

Kevin

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Andrew Cagney]

> On Sun, 29 Feb 2004 20:05:28 -0500
> Andrew Cagney <cagney@gnu.org> wrote:
> 
> 
>>>	* ppcnbsd-tdep.c: Include "trad-frame.h", and "frame-unwind.h".
>>>	(struct ppcnbsd_sigtramp_cache, ppcnbsd_sigtramp_this_id)
>>>	(ppcnbsd_sigtramp_prev_register, ppcnbsd_sigtramp_cache)
>>>	(ppcnbsd_sigtramp_sniffer, ppcnbsd_sigtramp_unwind)
>>>	(ppcnbsd_init_abi): Implement a NetBSD/PPC signal trampline
>>>	unwinder, register.
> 
> 
> After reading the disucssion, the only part about this which bothers
> me is the part that you yourself had a question about:
> 
> 
>>> +  if (frame_pc_unwind (next_frame) > 0x7f000000)
>>> +    /* Assume anything that is vaguely on the stack is a signal
>>> +       trampoline.  */
>>> +    return &ppcnbsd_sigtramp_unwind;
> 
> 
> Given Mark K's comments, I think it would be better to check for a
> specific instruction sequence.  I know it's expensive, but it seems
> like a more robust approach.  (But, also given Mark K's comments,
> it seems that a name based approach will work well in the future.)

We'd better wait for Jason's input then.  Jason will hopefully know 
exactly what the rules here are - which is better than us all guessing :-)

Andrew

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder

[Andrew Cagney]

> On Sun, 29 Feb 2004 20:05:28 -0500
> Andrew Cagney <cagney@gnu.org> wrote:
> 
> 
>>>	* ppcnbsd-tdep.c: Include "trad-frame.h", and "frame-unwind.h".
>>>	(struct ppcnbsd_sigtramp_cache, ppcnbsd_sigtramp_this_id)
>>>	(ppcnbsd_sigtramp_prev_register, ppcnbsd_sigtramp_cache)
>>>	(ppcnbsd_sigtramp_sniffer, ppcnbsd_sigtramp_unwind)
>>>	(ppcnbsd_init_abi): Implement a NetBSD/PPC signal trampline
>>>	unwinder, register.
> 
> 
> After reading the disucssion, the only part about this which bothers
> me is the part that you yourself had a question about:
> 
> 
>>> +  if (frame_pc_unwind (next_frame) > 0x7f000000)
>>> +    /* Assume anything that is vaguely on the stack is a signal
>>> +       trampoline.  */
>>> +    return &ppcnbsd_sigtramp_unwind;
> 
> 
> Given Mark K's comments, I think it would be better to check for a
> specific instruction sequence.  I know it's expensive, but it seems
> like a more robust approach.  (But, also given Mark K's comments,
> it seems that a name based approach will work well in the future.)

We'd better wait for Jason's input then.  Jason will hopefully know 
exactly what the rules here are - which is better than us all guessing :-)

Andrew