This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: target_resume_hook(), target_wait_loop_hook()
- To: jtc at redback dot com
- Subject: Re: target_resume_hook(), target_wait_loop_hook()
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 09 May 2001 20:34:18 -0400
- Cc: gdb at sourceware dot cygnus dot com
- References: <5mitmtswmr.fsf@jtc.redback.com>
> remote.c contains two function pointers target_resume_hook() and
> target_wait_loop_hook() which are currently used by the d10v and d30v
> targets for some sort of trace buffer support.
>
> Doing this at this location seems clearly wrong to me. While these
> targets may only support remote protocol and simulator back ends at
> present, it means that future back ends will have to either add
> support for these hooks or the targets will lose the ability to
> capture the trace buffer.
>
> I wonder why these hooks weren't installed in the target_resume() and
> target_wait() macros? I can't see anything obvious why this could not
> be done. But please note I'm not familiar with either target.
If they were moved to the target_*() then the corresponding hook code
would need to check the type of the current target (is it remote /
extended-remote?) before pokeing around to find the trace data.
I think this requrement is, in turn, a reflection of the limitations of
the current target stack implementation. Instead of inserting these
hooks into the target_*() macro's it should be possible for the
d10v/d30v to push an extra layer onto the target stack. Unfortunatly,
that isn't currently possible.
Andrew