This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: target_resume_hook(), target_wait_loop_hook()


> 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]