From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7721 invoked by alias); 2 Dec 2005 19:36:41 -0000 Received: (qmail 7710 invoked by uid 22791); 2 Dec 2005 19:36:40 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 Dec 2005 19:36:39 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id jB2Jaaum029041; Fri, 2 Dec 2005 20:36:36 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id jB2Jaal9006824; Fri, 2 Dec 2005 20:36:36 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id jB2JaZ6n014666; Fri, 2 Dec 2005 20:36:35 +0100 (CET) Date: Fri, 02 Dec 2005 19:36:00 -0000 Message-Id: <200512021936.jB2JaZ6n014666@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: andrew.stubbs@st.com CC: gdb@sourceware.org In-reply-to: <439090FE.8040502@st.com> (message from Andrew STUBBS on Fri, 02 Dec 2005 18:22:54 +0000) Subject: Re: [RFC] plugin/extension interface References: <439090FE.8040502@st.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00009.txt.bz2 > Date: Fri, 02 Dec 2005 18:22:54 +0000 > From: Andrew STUBBS > > Hi all, > > I would like to test the waters and find out what your opinion would be > on the subject of a GDB plugin/extension interface. My initial reaction (without reading the rest of your mail) would be "Not over my dead body!". In my experience plugin/extension interfaces add a lot of bloat, are difficult to maintain, and difficult to support. Look at the problems we've had with the libthread-db.so stuff on Linux and (to a lesser extent) Solaris. There are also GPL issues. > We, here at ST, have a custom target backend which is implemented as a > DLL connected to some custom code in GDB not totally unlike remote.c. We > did this because the remote protocol was too slow, too limited and > required some way to launch other processes which could then easily get > left over by mistake. > > Now we have reason to rewrite the interface - it is currently very > SH-centric and we wish to share it with another ST architecture - so I > am considering the various possibilities. > > One possibility (of which I am in favour) is to create a generic GDB > plugin interface which can become part of the official GDB. This course > of action is not yet certain, but the outcome of any discussion we have > here will probably influence the final decision (along with some other > local considerations). > > Desirable features (from our point of view): > - Target independent [1]. > - Architecture independent [1]. > - Flexible/Powerful enough not to limit capabilities. > - Debugger independent [2]. > - Extensible. > - Easy to maintain. > > It is largely this last requirement which prompts me to ask your opinion > - it will be easier to maintain if it is accepted into the official > source base, because we will not have to continually forward port it as > a local change. Obviously I am more likely to get something accepted if > you guys have agreed the interface in principle in advance. Why can't you just compile your remote protocol support code into GDB. That's the way it's been always done. It's simple, and works, and I think that'll actually be the easiest to maintain. Plugin/extension interfaces only make sense for third parties that want to distribute binary stuff. That doesn't make sense for an open source debugger. Mark