This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch/rfc] signal trampoline frames
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