Re: RFA: revised implementation of permanent breakpoints

[Jim Blandy <jimb AT cygnus dot com>]

> That is all I ask :-)

Woo hoo!  I got something right!  Michael and JimI have concluded that
I'm sans sanity, though, so I don't know whether it matters.  :)


> > + /* We can't step off a permanent breakpoint in the ordinary way, because we
> > +    can't remove it.  Instead, we have to advance the PC to the next
> > +    instruction.  This macro should expand to a pointer to a function that
> > +    does that, or zero if we have no such function.  If we don't have a
> > +    definition for it, we have to report an error.  */
> > + #ifndef SKIP_PERMANENT_BREAKPOINT
> > + #define SKIP_PERMANENT_BREAKPOINT ((void (*) (void)) 0)
> > + #endif
> > +
> > +
> 
> Puzzled expression.  Why is it being cast in that strange way.

Because I *really* like void.  I would have said ((void (*) ((void (*)
(void)), void (*) (void))) 0) if they'd let me, but they wouldn't.
They're so mean.

Because SKIP_PERMANENT_BREAKPOINT has to yield a value which I can
apply later, like `SKIP_PERMANENT_BREAKPOINT ().'  The compiler didn't
like `(0) ()'.

> > +   /* Normally, by the time we reach `resume', the breakpoints are either
> > +      removed or inserted, as appropriate.  The exception is if we're sitting
> > +      at a permanent breakpoint; we need to step over it, but permanent
> > +      breakpoints can't be removed.  So we have to test for it here.  */
> > +   if (breakpoint_here_p (read_pc ()) == permanent_breakpoint_here)
> > +     {
> > +       if (SKIP_PERMANENT_BREAKPOINT)
> > +       SKIP_PERMANENT_BREAKPOINT ();
> > +       else
> > +       {
> > +         error_begin ();
> > +         fprintf_filtered (gdb_stderr, "\
> > + The program is stopped at a permanent breakpoint, but GDB does not know\n\
> > + how to step past a permanent breakpoint on this architecture.  Try using\n\
> > + a command like `return' or `jump' to continue execution.\n");
> > +         return_to_top_level (RETURN_ERROR);
> > +       }
> > +     }
> 
> Ah, no. You can't directly test a macro for NULL. The good old ``have
> the macro name return a function pointer and then call that'' trick
> won't work.  This is because GDB arch is internally parameterized by the
> current architecture.

Ahh --- you have to stick an extra argument in there, so you always
generate macros which take arguments.  Gotcha.

Thanks for the help!