Re: [patch/rfc] signal trampoline frames

[Daniel Jacobowitz <drow@false.org>]

On Tue, Mar 23, 2004 at 07:02:45PM -0500, Andrew Cagney wrote:
> see attached?
> 
> >
> >>>+static CORE_ADDR
> >>>+tramp_frame_start (CORE_ADDR pc, const struct tramp_frame *tramp)
> >>>+{
> >>>+  int ti;
> >>>+  /* Search through the trampoline for one that matches the
> >>>+     instruction sequence around PC.  */
> >>>+  for (ti = 0; tramp->insn[ti] != 0; ti++)
> >>>+    {
> >>>+      CORE_ADDR func = pc - tramp->insn_size * ti;
> >>>+      int i;
> >>>+      for (i = 0; 1; i++)
> >>>+	{
> >>>+	  bfd_byte buf[sizeof (LONGEST)];
> >>>+	  CORE_ADDR insn;
> >
> >
> >tramp->insn is a ULONGEST.  Both of these should probably be ULONGEST
> >also.
> 
> changed to ->insn[0]

I was more concerned about the CORE_ADDR.

> >>>+	  if (tramp->insn[i] == 0)
> >>>+	    return func;
> >
> >
> >So zeros in tramp->insn mark the end of the sequence?  Should document
> >that, zeros are valid instructions and some bizarre architecture might
> >use one as a syscall trap.
> 
> Added TRAMP_SENTINEL_INSN, it _isn't_ zero.

The comment in the attached still says it's zero.  Zero and -1 are just
about equally likely/unlikely, so I don't think it matters what the
value is; I like having TRAMP_SENTINEL_INSN though.

> I don't know.

Doesn't much matter then.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer