This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: RFA: revised implementation of permanent breakpoints
- To: cagney AT cygnus dot com
- Subject: Re: RFA: revised implementation of permanent breakpoints
- From: Stan Shebs <shebs AT cygnus dot com>
- Date: Mon, 13 Sep 1999 16:50:08 -0700
- CC: jimb AT cygnus dot com, msnyder AT cygnus dot com, jingham AT cygnus dot com, gdb-patches AT sourceware.cygnus dot com
Date: Tue, 14 Sep 1999 09:42:34 +1000
From: Andrew Cagney <ac131313@cygnus.com>
> + /* 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.
Null pointer to a void function with no args, presumably.
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.
Instead, either a predicate needs to be added:
if (SKIP_PERMENANT_BREAPOINT_P)
SKIP_PERMENANT_BREAPOINT (...);
or better, just turn the else clause from the above into a function and
default the macro to that:
SKIP_PERMENANT_BREAKPOINT (...)
Originally I was thinking that you need to make the test first, so
that if the macro is empty, then GDB can at least tell the user that
something is wrong. But as you say, the default macro behavior should
be to issue the helpful message.
Stan