From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Nick Duffek Cc: cagney@cygnus.com, gdb-patches@sources.redhat.com Subject: Re: [RFA] add remote.c gdbarch thread-handling hooks Date: Mon, 16 Jul 2001 12:21:00 -0000 Message-id: <5mg0bwvfx1.fsf@jtc.redback.com> References: <200107161726.f6GHQ8P08542@rtl.cygnus.com> X-SW-Source: 2001-07/msg00384.html >>>>> "Nick" == Nick Duffek 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