Re: [RFA] add remote.c gdbarch thread-handling hooks

[jtc@redback.com (J.T. Conklin)]

>>>>> "Nick" == Nick Duffek <nsd@redhat.com> writes:
Nick> I've been working on an architecture with a primitive threading
Nick> mechanism that GDB queries and manipulates by directly setting
Nick> registers in the target.
Nick>
Nick> This patch facilitates that with hooks for target-specific code
Nick> to override remote.c thread-handling functions.

Until I'm convinced otherwise, I'm against adding this extension to
remote.c.

This change essentially creates a easy to use mechanism for creating
yet another remote protocol varient.  It's actually worse than that, 
since it overrides existing protocol.  While I think we support too
many protocol varients already, I'd be more sympathetic to a change
adding another varient than hijacking the existing protocol definitions.

Also, the remote protocol is intendent to be target neutral.  Why
can't the existing thread primitives be changed into the register
manipulation in the target's debug agent?  Although I don't have any
information on the architecture in question, this proposed change 
appears to tie GDB to one possible thread implementation.  

However, if it is true that this is the only thread model used under
this architecture, I the change is at the wrong level.  Binding it
into remote.c means that it won't be available to other back ends.  To
use this with an ICE or a ROM monitor, a user would have to write a
gdbserver-like program to attach to from GDB which would in turn talk
to the target.

        --jtc

-- 
J.T. Conklin
RedBack Networks