* [RFC] plugin/extension interface @ 2005-12-02 18:25 Andrew STUBBS 2005-12-02 18:49 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 32+ messages in thread From: Andrew STUBBS @ 2005-12-02 18:25 UTC (permalink / raw) To: GDB List 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. 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. It is also my goal that one day we will be able to use a GDB with no local patches, or at least only those relating to bugs that will be fixed in the next version. Obviously my recent contributions will go a long way toward this and getting the backend sorted would get me much closer still. [1] The target/architecture dependent parts should exist entirely in the DLL while the plugin interface remains neutral. [2] The DLL should also work with a simple loader front-end and, potentially, other debuggers, should the need arise (obviously a similar interface would have to be implemented in that debugger and the DLL would have to have understand debugger 'personalities'). Basically this means not just exporting the target_ops table. This is another reason why the remote protocol is undesirable in this case. I shall now outline one possible implementation of what I envisage. This is sufficiently similar to what ST has now not to cause me any undue work. It is also sufficiently generic that it should work for anybody else with similar requirements. User Interface Outline ---------------------- CLI commands: plugin load PLUGIN ARGS plugin unload PLUGIN plugin list (or info plugins ???) Any additional parameters passed to the load command will be passed through during initialisation. Upon load the DLL will register zero or more target interfaces and/or zero or more CLI commands. This includes set/show commands and nested commands - the appropriate built-in ones (info etc.) as well as groups it registers itself. If two plugins register the same target then that is an error. If two plugins register the same CLI command (say they both use the same set/show options) then each plugin will be notified when the command is issued. If the plugin requires exclusive use of a command then it must make its name unique in some way. Backend API Outline ------------------- The majority of the GDB specific parts of a (process stratum) target will be coded in GDB, much like the remote target. The DLL interface would then consist of low or medium level target manipulation calls. The DLL itself will provide all the knowledge of how to connect (given the parameters passed to the target command), but ought not need to know about the object files and such unless it wants to. The DLL must have symbols of the right name defined so that they can be properly hooked up using dlsym() (or GetProcAddress() on Windows). These will consist of functions for GDB to call and function pointers into which GDB may poke values for any reverse function calls. Some symbols will be compulsory and the load will fail if they do not exist and others will be optional, much as in the target_ops table currently. Compulsory functions (not complete, not final names): initialize deinitialize Compulsory when registering a target: attach detach read_mem write_mem read_reg write_reg resume step interrupt ...whatever other target_ops seems appropriate Optional functions (not complete, not final names): load } can be implemented with read/write compare_sections } but DLL may want to for efficiency set_breakpoint } and/or target specific correctness remove_breakpoint } set_hardware_breakpoint remove_hardware_breakpoint set_watchpoint remove_hardware_watchpoint disconnect ...thread stuff ...whatever other target_ops seems appropriate Optional function pointers (not complete, not final names): register_target register_gdb_command error print_filtered print_unfiltered call_gdb_cli ...access to other GDB internals as required (safely wrapped up) Obviously I haven't attempted to finalize the initial function set. The above gives a general picture of what I intend. I have an existing interface which approximately defines the minimum set, but after some parts have been migrated from GDB to the DLL (and perhaps vice-versa), and all the deprecated methods have been reimplemented, then I shall have a better understanding of exactly what is needed. The extensibility requirement can be met simply by changing the names of functions that change. e.g., "dlsym(init2); if (!init2) dlsym (init);". If the interface is not powerful/flexible enough for a plugin then extra calls may be added as required. That particular plugin will only work (fully) on that version of GDB (or newer), and all other plugins will be unaffected (they should not even need recompilation). Of course, the sky (and the complexity of the code) is the limit. It would, for example, be possible to add enough hooks to implement Insight as a plugin (perhaps not exactly as it is now), although I'm not recommending anybody tries! The debugger independence is provided by not using GDB specific names/arguments and by implementing as much of the GDB specific target interface as possible on the GDB side. The DLL will need to be aware of what it is connected to if it registers or calls CLI commands, but beyond that it should not have to worry too much. It may be that some optional features are not supported by all hosts, but they are optional. If you have read this far then thanks! I shall be away from next Thursday so I don't expect to get this decided this year and certainly not start any work until the new year, but all comments, ideas and general gut feelings would be appreciated. I would prefer to reach an agreement in principle before attempting to thrash out too many details. TIA Andrew Stubbs ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-02 18:25 [RFC] plugin/extension interface Andrew STUBBS @ 2005-12-02 18:49 ` Eli Zaretskii 2005-12-02 19:23 ` Daniel Jacobowitz 2005-12-02 19:36 ` Mark Kettenis 2005-12-05 16:17 ` Andrew STUBBS 2 siblings, 1 reply; 32+ messages in thread From: Eli Zaretskii @ 2005-12-02 18:49 UTC (permalink / raw) To: Andrew STUBBS; +Cc: gdb > Date: Fri, 02 Dec 2005 18:22:54 +0000 > From: Andrew STUBBS <andrew.stubbs@st.com> > > I would like to test the waters and find out what your opinion would be > on the subject of a GDB plugin/extension interface. Such suggestions (not only for GDB, for other GNU projects as well) are usually rejected by Richard Stallman and the FSF, because they make it possible to add to GDB significant new features with proprietary (i.e. non-free software) shared libraries, thus avoiding the need to release any parts of GDB under GPL. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-02 18:49 ` Eli Zaretskii @ 2005-12-02 19:23 ` Daniel Jacobowitz 0 siblings, 0 replies; 32+ messages in thread From: Daniel Jacobowitz @ 2005-12-02 19:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Andrew STUBBS, gdb On Fri, Dec 02, 2005 at 08:48:58PM +0200, Eli Zaretskii wrote: > > Date: Fri, 02 Dec 2005 18:22:54 +0000 > > From: Andrew STUBBS <andrew.stubbs@st.com> > > > > I would like to test the waters and find out what your opinion would be > > on the subject of a GDB plugin/extension interface. > > Such suggestions (not only for GDB, for other GNU projects as well) > are usually rejected by Richard Stallman and the FSF, because they > make it possible to add to GDB significant new features with > proprietary (i.e. non-free software) shared libraries, thus avoiding > the need to release any parts of GDB under GPL. I think we could discuss this with the FSF, if we had sufficiently compelling reasons. But, I don't think that we do, right now. Andrew, I can't support an interface like the one you've described. GDB is a hugely complicated program, with many independent areas; it's not clear to me which of those areas you're trying to make pluggable. It looks to me like it is specifically the target interface - just a very small piece of the pie. Also, new CLI commands. If that's right, the traditional solution to the target interface is a third party program which acts as a conversion tool between the GDB remote protocol and your proprietary target protocol, with whatever glue logic you would otherwise put into the plugin. The remote protocol serves as the boundary interface in the same way that the DLL boundary would serve as an interface. If what you want can't be done that way because of shortcomings in the protocol, we can fix them. This keeps the already-existing, documented, and supported remote protocol as the extent of GDB's obligation to remote targets. All the other bits you wanted to export as methods have less clear semantics, and some of them are guaranteed to change over time. GDB is burdened already with support for a huge number of targets using the _one_ interface; I don't want to deal with backwards compatibility. For new CLI commands, the right answer is probably to implement them in-core in some scripting language, and optionally pass things back to your remote target via "monitor" commands. The existing scripting language is inadequate. You can find preliminary (but usable) perl bindings in the mailing list archive. I've hacked Guile into GDB in the past, and when I can find some time, I intend to revisit the general problem (probably using Python, this time, since I'm most familiar with it at the moment). This requires some MI interface surgery and is not a small task. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-02 18:25 [RFC] plugin/extension interface Andrew STUBBS 2005-12-02 18:49 ` Eli Zaretskii @ 2005-12-02 19:36 ` Mark Kettenis 2005-12-02 22:12 ` Jim Blandy 2005-12-05 16:17 ` Andrew STUBBS 2 siblings, 1 reply; 32+ messages in thread From: Mark Kettenis @ 2005-12-02 19:36 UTC (permalink / raw) To: andrew.stubbs; +Cc: gdb > Date: Fri, 02 Dec 2005 18:22:54 +0000 > From: Andrew STUBBS <andrew.stubbs@st.com> > > 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-02 19:36 ` Mark Kettenis @ 2005-12-02 22:12 ` Jim Blandy 2005-12-02 22:16 ` Daniel Jacobowitz 2005-12-02 22:41 ` Mark Kettenis 0 siblings, 2 replies; 32+ messages in thread From: Jim Blandy @ 2005-12-02 22:12 UTC (permalink / raw) To: gdb I'm not so hostile to plug-in interfaces. It's true that the API needs to be designed carefully, but allowing people to maintain other features (targets; architectures; commands) separately from GDB would take a big load off our backs. It's true that plugin interfaces weaken the incentives the GPL tries to create, but while I think that was very important even five years ago, I don't think that's such a big deal any more. Maybe I don't get out enough, but I think there's already a consensus building that Open Source is simply the preferable way to develop programmers' tools, and most companies are just doing it freely, not because they have to use GPL'd ode. libthread_db has been a debacle, but I'd argue that's because it was designed for Solaris, and we lacked the option of adjusting the interface to better suit other systems. For example, the API doesn't abstract the process of stopping or continuing threads, meaning that it doesn't have the information it needs to cache things accurately in some cases (leading to bad performance) and that GDB pays the price in complexity of supporting the plugin interface, but ends up knowing a lot about the thread implementation anyway, so it doesn't get much benefit. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-02 22:12 ` Jim Blandy @ 2005-12-02 22:16 ` Daniel Jacobowitz 2005-12-02 22:41 ` Mark Kettenis 1 sibling, 0 replies; 32+ messages in thread From: Daniel Jacobowitz @ 2005-12-02 22:16 UTC (permalink / raw) To: Jim Blandy; +Cc: gdb On Fri, Dec 02, 2005 at 02:12:46PM -0800, Jim Blandy wrote: > I'm not so hostile to plug-in interfaces. It's true that the API > needs to be designed carefully, but allowing people to maintain other > features (targets; architectures; commands) separately from GDB would > take a big load off our backs. I don't think the benefit for targets or architectures is a particularly large one. Folks should expect to have to deal with core GDB for these, or use the remote protocol boundary. I do think we will want plugins eventually, but I haven't thought much about whether real dlopen'd plugins are worthwhile, or e.g. python. One classic example of this: domain-specific "shared library" objects for custom module loaders, like the Linux kernel's or X11's. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-02 22:12 ` Jim Blandy 2005-12-02 22:16 ` Daniel Jacobowitz @ 2005-12-02 22:41 ` Mark Kettenis 2005-12-02 23:07 ` Jim Blandy 1 sibling, 1 reply; 32+ messages in thread From: Mark Kettenis @ 2005-12-02 22:41 UTC (permalink / raw) To: jimb; +Cc: gdb > Date: Fri, 2 Dec 2005 14:12:46 -0800 > From: Jim Blandy <jimb@red-bean.com> > I'm not so hostile to plug-in interfaces. It's true that the API > needs to be designed carefully, but allowing people to maintain other > features (targets; architectures; commands) separately from GDB would > take a big load off our backs. I really doubt that. Short term it'd only increase the load since we have to build the plug-in interface. Long term, we still have to maintain that interface. We'll also get lots of support questions where the problems are really with the third party plugins, but where the bug reporter conveniently forgets to mention that he's using a third party plugin. Let's keep people out of our address space if they don't want to commit themselves to providing sources and manpower to maintain those sources. > libthread_db has been a debacle, but I'd argue that's because it was > designed for Solaris, and we lacked the option of adjusting the > interface to better suit other systems. For example, the API doesn't > abstract the process of stopping or continuing threads, meaning that > it doesn't have the information it needs to cache things accurately in > some cases (leading to bad performance) and that GDB pays the price in > complexity of supporting the plugin interface, but ends up knowing a > lot about the thread implementation anyway, so it doesn't get much > benefit. Never really realised it, but actually all that we use libthread_db for is mapping process IDs into use-level thread IDs. Suddenly HP's ttrace(2) interface makes sense to me; they have a field to store the user-level thread ID in the kernel. That way you really don't need any knwoledge about the threads implementation at all, except that there's a 1:1 mapping between LWPs and user-level threads. What I meant by the libthread_db debacle is the fact that gdb picks up the wrong version of it sometimes and that this makes things fail in nonobvious ways. Not the fact that trying to support several different kernels and threads libraries, most of which have serious bugs, is really erh... difficult. Mark ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-02 22:41 ` Mark Kettenis @ 2005-12-02 23:07 ` Jim Blandy 2005-12-02 23:13 ` Bob Rossi 2005-12-02 23:32 ` Daniel Jacobowitz 0 siblings, 2 replies; 32+ messages in thread From: Jim Blandy @ 2005-12-02 23:07 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb On 12/2/05, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > I really doubt that. Short term it'd only increase the load since we > have to build the plug-in interface. Long term, we still have to > maintain that interface. We'll also get lots of support questions > where the problems are really with the third party plugins, but where > the bug reporter conveniently forgets to mention that he's using a > third party plugin. Let's keep people out of our address space if > they don't want to commit themselves to providing sources and manpower > to maintain those sources. I don't think you're seeing the potential here. There are a *lot* of things people would like to do with debuggers: it's one of the best fields for productive creeping featurism you can imagine. Writ broad, a debugger is a program for watching your program run. That's open to so much application-specific interpretation it's actually hard to imagine how generic code (like GDB) would even be useful, if you haven't seen it in action. In other words, if the plug-ins had enough hooks to customize GDB's behavior (printing values, or decoding the stack, say), I think you'd be really surprised what people would do with it. They'd do tons of stuff that we'd never want to include in the core distribution, but which would add enormous value to GDB for their problems. And of course, there would be a few that we'd want to incorporate. To take another tack: plug-ins were vital to Apache's success. Why wouldn't they have the same effect on GDB? The only qualification I'd make here is that GDB's current internal organization isn't very friendly to this kind of stuff. A plug-in interface that could engender the kind of stuff I'm describing would have to be pretty clean, high-level, and documented. I could certainly see the argument that it's too much work to bring things to the point where they could bring about the benefits. ... Okay, another qualification is that a well-integrated scripting language might do everything I'm saying here, and better, because the extension/core interface is more well-defined. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-02 23:07 ` Jim Blandy @ 2005-12-02 23:13 ` Bob Rossi 2005-12-02 23:32 ` Daniel Jacobowitz 1 sibling, 0 replies; 32+ messages in thread From: Bob Rossi @ 2005-12-02 23:13 UTC (permalink / raw) To: Jim Blandy; +Cc: Mark Kettenis, gdb On Fri, Dec 02, 2005 at 03:07:29PM -0800, Jim Blandy wrote: > On 12/2/05, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > I really doubt that. Short term it'd only increase the load since we > > have to build the plug-in interface. Long term, we still have to > > maintain that interface. We'll also get lots of support questions > > where the problems are really with the third party plugins, but where > > the bug reporter conveniently forgets to mention that he's using a > > third party plugin. Let's keep people out of our address space if > > they don't want to commit themselves to providing sources and manpower > > to maintain those sources. > > The only qualification I'd make here is that GDB's current internal > organization isn't very friendly to this kind of stuff. A plug-in > interface that could engender the kind of stuff I'm describing would > have to be pretty clean, high-level, and documented. I could > certainly see the argument that it's too much work to bring things to > the point where they could bring about the benefits. I'm already in the long process of creating a level on top of GDB using MI that allows another process to do anything it wants with GDB. IMO, that is already the clean, high-level, documented interface that other applications should use to communicate with GDB. If the interface needs to change, that's where the effort should go. I don't think providing any other plugin interface besides what's described above even makes sense since it would be duplicating the effort. Bob Rossi ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-02 23:07 ` Jim Blandy 2005-12-02 23:13 ` Bob Rossi @ 2005-12-02 23:32 ` Daniel Jacobowitz 2005-12-03 0:57 ` Jim Blandy 1 sibling, 1 reply; 32+ messages in thread From: Daniel Jacobowitz @ 2005-12-02 23:32 UTC (permalink / raw) To: Jim Blandy; +Cc: Mark Kettenis, gdb On Fri, Dec 02, 2005 at 03:07:29PM -0800, Jim Blandy wrote: > I don't think you're seeing the potential here. There are a *lot* of > things people would like to do with debuggers: And every one of these things you've described doing with debuggers, would require a _DIFFERENT_ plugin interface. It would be a nightmare to add this to today's GDB! See Bob's comment for the right way to handle this problem, in my opinion also. I consider all this part of the "front end". Most of these things shouldn't be added to GDB at such a level that it gets exposed through MI; you should add it to your front end in a front end specific fashion. Often this means you need to add it to the GDB CLI also. That's a different sort of problem. Scripting languages, rather than plugin interfaces, are more viable for this. All this, of course, is moot until someone begins to implement it. But I have yet to see a binary plugin interface that doesn't have all the problems Mark described. > ... Okay, another qualification is that a well-integrated scripting > language might do everything I'm saying here, and better, because the > extension/core interface is more well-defined. Yes. I believe this will be the thing that pushes us up to version 7. I hope it will be soon, time and volunteers permitting. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-02 23:32 ` Daniel Jacobowitz @ 2005-12-03 0:57 ` Jim Blandy 2005-12-03 2:32 ` Daniel Jacobowitz 0 siblings, 1 reply; 32+ messages in thread From: Jim Blandy @ 2005-12-03 0:57 UTC (permalink / raw) To: Jim Blandy, Mark Kettenis, gdb On 12/2/05, Daniel Jacobowitz <drow@false.org> wrote: > And every one of these things you've described doing with debuggers, > would require a _DIFFERENT_ plugin interface. It would be a nightmare > to add this to today's GDB! Oh, I figured we'd just let the plugin code #include GDB's headers directly, so they could get at whatever they wanted. ... okay, that does sound like a nightmare. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 0:57 ` Jim Blandy @ 2005-12-03 2:32 ` Daniel Jacobowitz 2005-12-03 2:41 ` Russell Shaw 2005-12-03 2:41 ` Bob Rossi 0 siblings, 2 replies; 32+ messages in thread From: Daniel Jacobowitz @ 2005-12-03 2:32 UTC (permalink / raw) To: Jim Blandy; +Cc: Mark Kettenis, gdb On Fri, Dec 02, 2005 at 04:57:01PM -0800, Jim Blandy wrote: > On 12/2/05, Daniel Jacobowitz <drow@false.org> wrote: > > And every one of these things you've described doing with debuggers, > > would require a _DIFFERENT_ plugin interface. It would be a nightmare > > to add this to today's GDB! > > Oh, I figured we'd just let the plugin code #include GDB's headers > directly, so they could get at whatever they wanted. > > ... okay, that does sound like a nightmare. Now we're communicating :-) For the record, here's my overall point in this thread. We have some very good abstraction layers already: in particular, I'm talking about the remote protocol, and the MI/interpreters mechanism. I want GDB to be more extensible, but I believe that those protocols are the best way to do it. They both have limitations for this kind of use, because they aren't used that way yet; but what we need to do is commit to using them, then bite the bullet and begin improving them to meet our needs. That way we can keep the interfaces coherent, and hopefully, documented at or above today's levels. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 2:32 ` Daniel Jacobowitz @ 2005-12-03 2:41 ` Russell Shaw 2005-12-03 2:45 ` Daniel Jacobowitz 2005-12-03 2:41 ` Bob Rossi 1 sibling, 1 reply; 32+ messages in thread From: Russell Shaw @ 2005-12-03 2:41 UTC (permalink / raw) Cc: gdb Daniel Jacobowitz wrote: > On Fri, Dec 02, 2005 at 04:57:01PM -0800, Jim Blandy wrote: > >>On 12/2/05, Daniel Jacobowitz <drow@false.org> wrote: >> >>>And every one of these things you've described doing with debuggers, >>>would require a _DIFFERENT_ plugin interface. It would be a nightmare >>>to add this to today's GDB! >> >>Oh, I figured we'd just let the plugin code #include GDB's headers >>directly, so they could get at whatever they wanted. >> >>... okay, that does sound like a nightmare. > > Now we're communicating :-) > > For the record, here's my overall point in this thread. We have some > very good abstraction layers already: in particular, I'm talking about > the remote protocol, and the MI/interpreters mechanism. I want GDB to > be more extensible, but I believe that those protocols are the best way > to do it. They both have limitations for this kind of use, because > they aren't used that way yet; but what we need to do is commit to > using them, then bite the bullet and begin improving them to meet our > needs. > > That way we can keep the interfaces coherent, and hopefully, > documented at or above today's levels. Months ago, i added a remote protocol for a hardware in-circuit emulator and was going to write a chapter documenting how to add a target protocol to gdb. My questions on how best to add this to gdb in cvs got no response whatsoever. Now i've lost all interest. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 2:41 ` Russell Shaw @ 2005-12-03 2:45 ` Daniel Jacobowitz 2005-12-03 3:13 ` Russell Shaw 0 siblings, 1 reply; 32+ messages in thread From: Daniel Jacobowitz @ 2005-12-03 2:45 UTC (permalink / raw) To: Russell Shaw; +Cc: gdb On Sat, Dec 03, 2005 at 01:41:35PM +1100, Russell Shaw wrote: > Months ago, i added a remote protocol for a hardware in-circuit emulator > and was going to write a chapter documenting how to add a target protocol > to gdb. My questions on how best to add this to gdb in cvs got no response > whatsoever. Now i've lost all interest. [Off-topic here, but] I can't even remember seeing messages from you on this topic; a certain amount of persistance is always called for in GDB development. However, in general, I've come to believe that GDB shouldn't continue to add support for new remote protocols. What we need is a nice, open-source framework for gdb remote <-> other remote conversion. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 2:45 ` Daniel Jacobowitz @ 2005-12-03 3:13 ` Russell Shaw 2005-12-03 3:33 ` Daniel Jacobowitz 0 siblings, 1 reply; 32+ messages in thread From: Russell Shaw @ 2005-12-03 3:13 UTC (permalink / raw) Cc: gdb Daniel Jacobowitz wrote: > On Sat, Dec 03, 2005 at 01:41:35PM +1100, Russell Shaw wrote: > >>Months ago, i added a remote protocol for a hardware in-circuit emulator >>and was going to write a chapter documenting how to add a target protocol >>to gdb. My questions on how best to add this to gdb in cvs got no response >>whatsoever. Now i've lost all interest. > > [Off-topic here, but] > > I can't even remember seeing messages from you on this topic; a certain > amount of persistance is always called for in GDB development. > > However, in general, I've come to believe that GDB shouldn't continue > to add support for new remote protocols. What we need is a nice, > open-source framework for gdb remote <-> other remote conversion. The way gdb works, when i type: target avrjtagice -d /dev/ttyS2, gdb uses (or registers) using: void _initialize_remote_jtag (void). It really looks like gdb is "loading" the module. If the functions (or framework) used in these target interfaces are documented, the problems would be solved with little other than a bit of documentation work. I couldn't use the default target protocol, because i wasn't interfacing to an end target. I was interfacing to an ICE debugger (that already had its own protocol) for the target. I did it to replace the current hack of having an extra program on the pc that converts between the default gdb target protocol, and this ICE- specific protocol. The conversion hack was extremely slow, clumsy, fault-intolerant, and error-prone. With the specific interface in gdb, the performance was wonderful, and new gdb commands can be easily registered for this ICE, that are only accessible after the command "target avrjtagice -d /dev/ttyS2" is performed (like an emacs minor mode or whatever). Currently, the files for these specific interfaces are just chucked into gdb-6.3/gdb/ (such as remote-e7000.c). What's really needed is a separate sub-directory for each of these remote-interface protocol files, and a well documented api for what functions to use within them. The api already exists, just look in any db-6.3/gdb/remote*.c. One of the subdirectories can be devoted to the generic target protocol where the comms is to the end embedded system, instead of an intermediate debugger box. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 3:13 ` Russell Shaw @ 2005-12-03 3:33 ` Daniel Jacobowitz 2005-12-03 4:05 ` Russell Shaw 0 siblings, 1 reply; 32+ messages in thread From: Daniel Jacobowitz @ 2005-12-03 3:33 UTC (permalink / raw) To: Russell Shaw; +Cc: gdb On Sat, Dec 03, 2005 at 02:13:11PM +1100, Russell Shaw wrote: > The way gdb works, when i type: target avrjtagice -d /dev/ttyS2, > gdb uses (or registers) using: void _initialize_remote_jtag (void). Incorrect; that happens at GDB startup. > If the functions (or framework) used in these target interfaces are > documented, the problems would be solved with little other than a bit > of documentation work. Not unless we declared them a public interface. That means supporting them, preserving compatibility, et cetera. We are not prepared to do that. > I couldn't use the default target protocol, because i wasn't interfacing > to an end target. I was interfacing to an ICE debugger (that already had > its own protocol) for the target. > > I did it to replace the current hack of having an extra program on the > pc that converts between the default gdb target protocol, and this ICE- > specific protocol. > > The conversion hack was extremely slow, clumsy, fault-intolerant, and > error-prone. I would need to know a lot more about these problems, but it is very likely that they are problems with the conversion program - not with the concept. If they were problems with the remote protocol, we would be interested in fixing them. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 3:33 ` Daniel Jacobowitz @ 2005-12-03 4:05 ` Russell Shaw 2005-12-03 4:14 ` Daniel Jacobowitz 0 siblings, 1 reply; 32+ messages in thread From: Russell Shaw @ 2005-12-03 4:05 UTC (permalink / raw) Cc: gdb Daniel Jacobowitz wrote: > On Sat, Dec 03, 2005 at 02:13:11PM +1100, Russell Shaw wrote: > >>The way gdb works, when i type: target avrjtagice -d /dev/ttyS2, >>gdb uses (or registers) using: void _initialize_remote_jtag (void). > > Incorrect; that happens at GDB startup. > >>If the functions (or framework) used in these target interfaces are >>documented, the problems would be solved with little other than a bit >>of documentation work. > > Not unless we declared them a public interface. That means supporting > them, preserving compatibility, et cetera. We are not prepared to do > that. Well that's just too bad. It's the best way to go. Atleast i can support my own private gdb and cut the cruft that's been holding it back for years. >>I couldn't use the default target protocol, because i wasn't interfacing >>to an end target. I was interfacing to an ICE debugger (that already had >>its own protocol) for the target. >> >>I did it to replace the current hack of having an extra program on the >>pc that converts between the default gdb target protocol, and this ICE- >>specific protocol. >> >>The conversion hack was extremely slow, clumsy, fault-intolerant, and >>error-prone. > > I would need to know a lot more about these problems, but it is very > likely that they are problems with the conversion program - not with > the concept. If they were problems with the remote protocol, we would > be interested in fixing them. The very concept of making a protocol conversion program act like an end target is totally flawed. First there's the tediousness of starting and initializing the converter program and comms from it to the debugger box. Then the gdb<->debugger comms must be established. Then the debugger<->embedded-system comms and setup needs to be established using gdb. Any hang-ups in the converter program or debugger means redoing the whole process. The whole chain is extra slow because round-trip comms thru gdb<->converter<->debugger<->target-system is limited by the context switching of the pc between the gdb and converter processes. There is also the extra tediousness of debugging the converter program and trying to feed it with comms data using gdb, at the same time as having yet another gdb to debug the actual converter. The second problem is that ICE hardware and other debuggers have various specific commands such as for setting ICE hardware parameters, selecting memory spaces, setting breakpoint paramteters, and a ton of other stuff that a generic protocol has no hope of addressing. I found that by registering my own commands with add_com(), i can do all kinds of excellent things such as spit out on the gdb output window a tabulated list of the fuse settings in a microcontroller, or display and set the current ICE hardware settings. With a defined interface for vendors to control specific debugger hardware, gdb would get a lot more interest and move lightyears ahead. All i've seen is stagnation ever since i've had an interest in gdb 5 years ago. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 4:05 ` Russell Shaw @ 2005-12-03 4:14 ` Daniel Jacobowitz 2005-12-03 4:44 ` Russell Shaw 0 siblings, 1 reply; 32+ messages in thread From: Daniel Jacobowitz @ 2005-12-03 4:14 UTC (permalink / raw) To: Russell Shaw; +Cc: gdb On Sat, Dec 03, 2005 at 03:05:25PM +1100, Russell Shaw wrote: > Well that's just too bad. It's the best way to go. Atleast i can support > my own private gdb and cut the cruft that's been holding it back for years. You can do that anyway. Maintain your own source tree based on a current release; it's not that hard, lots of people do this already. > The very concept of making a protocol conversion program act like an > end target is totally flawed. Obviously I disagree; I don't find any of the limitations you describe to be a serious problem in practice. And yes, we've written and used several of these shim layers here. > The second problem is that ICE hardware and other debuggers have > various specific commands such as for setting ICE hardware > parameters, selecting memory spaces, setting breakpoint paramteters, > and a ton of other stuff that a generic protocol has no hope of > addressing. Please see the "monitor" command, which lets you pass whatever you wish to the convertor. This and a couple of user-defined commands are most of what you need... > I found that by registering my own commands with add_com(), i can do > all kinds of excellent things such as spit out on the gdb output > window a tabulated list of the fuse settings in a microcontroller, or > display and set the current ICE hardware settings. ... and they can provide arbitrary output, also. If it's inadequate for what you want to do with it, please provide specific examples, and we can fix it. > With a defined interface for vendors to control specific debugger > hardware, gdb would get a lot more interest and move lightyears > ahead. All i've seen is stagnation ever since i've had an interest in > gdb 5 years ago. You might be surprised to know that there's a thriving market for this sort of conversion layer already, e.g. OCDRemote. As for the state of GDB, that's a separate thread, and making progress already. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 4:14 ` Daniel Jacobowitz @ 2005-12-03 4:44 ` Russell Shaw 2005-12-03 4:49 ` Daniel Jacobowitz ` (2 more replies) 0 siblings, 3 replies; 32+ messages in thread From: Russell Shaw @ 2005-12-03 4:44 UTC (permalink / raw) Cc: gdb Daniel Jacobowitz wrote: > On Sat, Dec 03, 2005 at 03:05:25PM +1100, Russell Shaw wrote: > >>Well that's just too bad. It's the best way to go. Atleast i can support >>my own private gdb and cut the cruft that's been holding it back for years. > > > You can do that anyway. Maintain your own source tree based on a > current release; it's not that hard, lots of people do this already. > > >>The very concept of making a protocol conversion program act like an >>end target is totally flawed. > > > Obviously I disagree; I don't find any of the limitations you describe > to be a serious problem in practice. > > And yes, we've written and used several of these shim layers here. > > >>The second problem is that ICE hardware and other debuggers have >>various specific commands such as for setting ICE hardware >>parameters, selecting memory spaces, setting breakpoint paramteters, >>and a ton of other stuff that a generic protocol has no hope of >>addressing. > > > Please see the "monitor" command, which lets you pass whatever you wish > to the convertor. This and a couple of user-defined commands are most > of what you need... Looking at gdb docs, i couldn't find any "monitor" command or in the index. (gdb) help monitor Send a command to the remote monitor (remote targets only). Not very helpful. Anyway, preceding every command with "monitor" is hardly a nice or intuitive user interface. >>I found that by registering my own commands with add_com(), i can do >>all kinds of excellent things such as spit out on the gdb output >>window a tabulated list of the fuse settings in a microcontroller, or >>display and set the current ICE hardware settings. > > > ... and they can provide arbitrary output, also. If it's inadequate > for what you want to do with it, please provide specific examples, and > we can fix it. > > >>With a defined interface for vendors to control specific debugger >>hardware, gdb would get a lot more interest and move lightyears >>ahead. All i've seen is stagnation ever since i've had an interest in >>gdb 5 years ago. > > > You might be surprised to know that there's a thriving market for this > sort of conversion layer already, e.g. OCDRemote. http://www.macraigor.com/full_gnu.htm All this daemon stuff to convert a generic protocol to a hardware-specific protocol is slow and ineligant IMO. > As for the state of GDB, that's a separate thread, and making progress > already. If there was an api for hardware-specific protocols, not only would performance of these improve, but there would be new developers seeing gdb code and having an interest in maintaining and improving it (i was really the first example). What's more, all kinds of unsupported debugger hardware could be added by users. Because each hardware goes into its own subdirectory, it doesn't complicate any other area of gdb and can be easily removed. That's how the backend of gcc works. Changes in gdb that break these interfaces simply mean the maintainers of them can adapt to the change, so not hindering gdb development. A problem with the current method of using shims is that if you want to develop one, you have to go out and find one on the net to find a place to start. With all the interfaces in gdb subdirectories, all the example code that anyone could ever want for adding support for new hardware, is already there to look at (i looked at gdb-6.3/gdb/remote*.c to start my one). ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 4:44 ` Russell Shaw @ 2005-12-03 4:49 ` Daniel Jacobowitz 2005-12-03 5:25 ` Russell Shaw 2005-12-03 5:06 ` [RFC] plugin/extension interface Russell Shaw 2005-12-03 9:29 ` Eli Zaretskii 2 siblings, 1 reply; 32+ messages in thread From: Daniel Jacobowitz @ 2005-12-03 4:49 UTC (permalink / raw) To: Russell Shaw; +Cc: gdb On Sat, Dec 03, 2005 at 03:44:31PM +1100, Russell Shaw wrote: > >Please see the "monitor" command, which lets you pass whatever you wish > >to the convertor. This and a couple of user-defined commands are most > >of what you need... > > Looking at gdb docs, i couldn't find any "monitor" command or in the index. > > (gdb) help monitor > > Send a command to the remote monitor (remote targets only). Found `monitor' in Index. (`,' tries to find next.) `monitor CMD' This command allows you to send commands directly to the remote monitor. > Not very helpful. That's because the bits that go after the word "monitor" depend on your target :-) > Anyway, preceding every command with "monitor" is hardly a nice or intuitive > user interface. Of course. Provide a GDB script file that uses "define" to give things pretty names, for example. > >As for the state of GDB, that's a separate thread, and making progress > >already. > > If there was an api for hardware-specific protocols, not only would > performance of these improve, but there would be new developers > seeing gdb code and having an interest in maintaining and improving > it (i was really the first example). What's more, all kinds of > unsupported debugger hardware could be added by users. Because each > hardware goes into its own subdirectory, it doesn't complicate any > other area of gdb and can be easily removed. That's how the backend > of gcc works. I'm not convinced that performance is an issue here. I'd need numbers. The total data transfer over the remote protocol is, usually, very small - even if you're doing application downloads, it's just a couple of extra buffer copies on the local system. If you expect to be transfering huge data sessions, use a local pipe or fifo to connect to the daemon instead of TCP. > A problem with the current method of using shims is that if you want > to develop one, you have to go out and find one on the net to find a > place to start. > > With all the interfaces in gdb subdirectories, all the example code that > anyone could ever want for adding support for new hardware, is already > there to look at (i looked at gdb-6.3/gdb/remote*.c to start my one). If you wanted to add a skeleton protocol conversion daemon to the GDB source tree, especially under the GPL, I'm sure we'd be glad to include it! The problem with "remote*.c" is that most of them haven't been used in years. Many of them are bad examples, or simply broken. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 4:49 ` Daniel Jacobowitz @ 2005-12-03 5:25 ` Russell Shaw 2005-12-03 12:49 ` [commit] Clarify "monitor" command (was: [RFC] plugin/extension interface) Eli Zaretskii 0 siblings, 1 reply; 32+ messages in thread From: Russell Shaw @ 2005-12-03 5:25 UTC (permalink / raw) Cc: gdb Daniel Jacobowitz wrote: > On Sat, Dec 03, 2005 at 03:44:31PM +1100, Russell Shaw wrote: > >>>Please see the "monitor" command, which lets you pass whatever you wish >>>to the convertor. This and a couple of user-defined commands are most >>>of what you need... >> >>Looking at gdb docs, i couldn't find any "monitor" command or in the index. >> >>(gdb) help monitor >> >> Send a command to the remote monitor (remote targets only). > > Found `monitor' in Index. (`,' tries to find next.) > > `monitor CMD' > This command allows you to send commands directly to the remote > monitor. > >>Not very helpful. > > That's because the bits that go after the word "monitor" depend on your > target :-) > >>Anyway, preceding every command with "monitor" is hardly a nice or intuitive >>user interface. > > Of course. Provide a GDB script file that uses "define" to give things > pretty names, for example. It would be useful if the manual actually said that this is the way to add new commands for an external monitor. It is bad when i can only learn new things about gdb by complaining. >>>As for the state of GDB, that's a separate thread, and making progress >>>already. >> >>If there was an api for hardware-specific protocols, not only would >>performance of these improve, but there would be new developers >>seeing gdb code and having an interest in maintaining and improving >>it (i was really the first example). What's more, all kinds of >>unsupported debugger hardware could be added by users. Because each >>hardware goes into its own subdirectory, it doesn't complicate any >>other area of gdb and can be easily removed. That's how the backend >>of gcc works. > > I'm not convinced that performance is an issue here. I'd need numbers. > The total data transfer over the remote protocol is, usually, very > small - even if you're doing application downloads, it's just a couple > of extra buffer copies on the local system. If you expect to be > transfering huge data sessions, use a local pipe or fifo to connect to > the daemon instead of TCP. > >>A problem with the current method of using shims is that if you want >>to develop one, you have to go out and find one on the net to find a >>place to start. >> >>With all the interfaces in gdb subdirectories, all the example code that >>anyone could ever want for adding support for new hardware, is already >>there to look at (i looked at gdb-6.3/gdb/remote*.c to start my one). > > If you wanted to add a skeleton protocol conversion daemon to the GDB > source tree, especially under the GPL, I'm sure we'd be glad to include > it! > > The problem with "remote*.c" is that most of them haven't been used in > years. Many of them are bad examples, or simply broken. I suppose i could start the shim daemon from a .gdbinit file using the gdb "shell" command. An explanation about shims and how to implement them in a way that is non-tedious to use, should be in the manual. Last time i read the remote protocol spec in the gdb manual, most of it was too terse to be useable. ^ permalink raw reply [flat|nested] 32+ messages in thread
* [commit] Clarify "monitor" command (was: [RFC] plugin/extension interface) 2005-12-03 5:25 ` Russell Shaw @ 2005-12-03 12:49 ` Eli Zaretskii 2005-12-03 12:51 ` [commit] Clarify "monitor" command Russell Shaw 2005-12-03 16:08 ` [commit] Clarify "monitor" command (was: [RFC] plugin/extension interface) Daniel Jacobowitz 0 siblings, 2 replies; 32+ messages in thread From: Eli Zaretskii @ 2005-12-03 12:49 UTC (permalink / raw) To: Russell Shaw; +Cc: gdb, gdb-patches > Date: Sat, 03 Dec 2005 16:25:41 +1100 > From: Russell Shaw <rjshaw@netspace.net.au> > Cc: gdb@sourceware.org > > It would be useful if the manual actually said that this is the way to > add new commands for an external monitor. It is bad when i can only learn > new things about gdb by complaining. Thank you for pointing this out. I've just committed the following change to the GDB manual: 2005-12-03 Eli Zaretskii <eliz@gnu.org> * gdb.texinfo (Connecting): Explain that `monitor' is a way to extend GDB with commands for external monitor. Index: gdb/doc/gdb.texinfo =================================================================== RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v retrieving revision 1.298 diff -u -r1.298 gdb.texinfo --- gdb/doc/gdb.texinfo 2 Dec 2005 11:44:19 -0000 1.298 +++ gdb/doc/gdb.texinfo 3 Dec 2005 12:42:11 -0000 @@ -11966,10 +11966,15 @@ another target. @cindex send command to remote monitor +@cindex extend @value{GDBN} for remote targets +@cindex add new commands for external monitor @kindex monitor @item monitor @var{cmd} -This command allows you to send commands directly to the remote -monitor. +This command allows you to send arbitrary commands directly to the +remote monitor. Since @value{GDBN} doesn't care about the commands it +sends like this, this command is the way to extend @value{GDBN}---you +can add new commands that only the external monitor will understand +and implement. @end table @node Server ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [commit] Clarify "monitor" command 2005-12-03 12:49 ` [commit] Clarify "monitor" command (was: [RFC] plugin/extension interface) Eli Zaretskii @ 2005-12-03 12:51 ` Russell Shaw 2005-12-03 16:08 ` [commit] Clarify "monitor" command (was: [RFC] plugin/extension interface) Daniel Jacobowitz 1 sibling, 0 replies; 32+ messages in thread From: Russell Shaw @ 2005-12-03 12:51 UTC (permalink / raw) Cc: gdb Eli Zaretskii wrote: >>Date: Sat, 03 Dec 2005 16:25:41 +1100 >>From: Russell Shaw <rjshaw@netspace.net.au> >>Cc: gdb@sourceware.org >> >>It would be useful if the manual actually said that this is the way to >>add new commands for an external monitor. It is bad when i can only learn >>new things about gdb by complaining. > > Thank you for pointing this out. I've just committed the following > change to the GDB manual: > > 2005-12-03 Eli Zaretskii <eliz@gnu.org> > > * gdb.texinfo (Connecting): Explain that `monitor' is a way to > extend GDB with commands for external monitor. Thanks. A decent manual makes all the difference;) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [commit] Clarify "monitor" command (was: [RFC] plugin/extension interface) 2005-12-03 12:49 ` [commit] Clarify "monitor" command (was: [RFC] plugin/extension interface) Eli Zaretskii 2005-12-03 12:51 ` [commit] Clarify "monitor" command Russell Shaw @ 2005-12-03 16:08 ` Daniel Jacobowitz 1 sibling, 0 replies; 32+ messages in thread From: Daniel Jacobowitz @ 2005-12-03 16:08 UTC (permalink / raw) To: gdb On Sat, Dec 03, 2005 at 02:48:47PM +0200, Eli Zaretskii wrote: > > Date: Sat, 03 Dec 2005 16:25:41 +1100 > > From: Russell Shaw <rjshaw@netspace.net.au> > > Cc: gdb@sourceware.org > > > > It would be useful if the manual actually said that this is the way to > > add new commands for an external monitor. It is bad when i can only learn > > new things about gdb by complaining. You can also learn new things by asking questions :-) > Thank you for pointing this out. I've just committed the following > change to the GDB manual: Thanks, Eli! I was going to do this today, but you beat me to it as usual :-) -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 4:44 ` Russell Shaw 2005-12-03 4:49 ` Daniel Jacobowitz @ 2005-12-03 5:06 ` Russell Shaw 2005-12-03 5:12 ` Daniel Jacobowitz 2005-12-03 9:29 ` Eli Zaretskii 2 siblings, 1 reply; 32+ messages in thread From: Russell Shaw @ 2005-12-03 5:06 UTC (permalink / raw) Cc: gdb Russell Shaw wrote: > Daniel Jacobowitz wrote: > >> On Sat, Dec 03, 2005 at 03:05:25PM +1100, Russell Shaw wrote: >> ... > With all the interfaces in gdb subdirectories, all the example code that > anyone could ever want for adding support for new hardware, is already > there to look at (i looked at gdb-6.3/gdb/remote*.c to start my one). Maybe these subdirectories should actually be for each cpu type, and any hardware debugger protocols should be in a subdirectory of that. This would simplify the source tree of gdb *alot*. Currently: gdb-6.3/gdb/remote-hms.c gdb-6.3/gdb/h8300-tdep.c New: gdb-6.3/gdb/h8300/remote/hms.c gdb-6.3/gdb/h8300/tdep.c ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 5:06 ` [RFC] plugin/extension interface Russell Shaw @ 2005-12-03 5:12 ` Daniel Jacobowitz 0 siblings, 0 replies; 32+ messages in thread From: Daniel Jacobowitz @ 2005-12-03 5:12 UTC (permalink / raw) To: Russell Shaw; +Cc: gdb On Sat, Dec 03, 2005 at 04:05:59PM +1100, Russell Shaw wrote: > Russell Shaw wrote: > >Daniel Jacobowitz wrote: > > > >>On Sat, Dec 03, 2005 at 03:05:25PM +1100, Russell Shaw wrote: > >> > ... > >With all the interfaces in gdb subdirectories, all the example code that > >anyone could ever want for adding support for new hardware, is already > >there to look at (i looked at gdb-6.3/gdb/remote*.c to start my one). > > Maybe these subdirectories should actually be for each cpu type, > and any hardware debugger protocols should be in a subdirectory > of that. > > This would simplify the source tree of gdb *alot*. > > Currently: > > gdb-6.3/gdb/remote-hms.c > gdb-6.3/gdb/h8300-tdep.c > > New: > > gdb-6.3/gdb/h8300/remote/hms.c > gdb-6.3/gdb/h8300/tdep.c We've talked about doing this before, but some people like it and others don't, so we've left alone - also, CVS notoriously doesn't like renaming files. It doesn't make a whole lot of difference. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 4:44 ` Russell Shaw 2005-12-03 4:49 ` Daniel Jacobowitz 2005-12-03 5:06 ` [RFC] plugin/extension interface Russell Shaw @ 2005-12-03 9:29 ` Eli Zaretskii 2005-12-03 9:50 ` Russell Shaw 2 siblings, 1 reply; 32+ messages in thread From: Eli Zaretskii @ 2005-12-03 9:29 UTC (permalink / raw) To: Russell Shaw; +Cc: gdb > Date: Sat, 03 Dec 2005 15:44:31 +1100 > From: Russell Shaw <rjshaw@netspace.net.au> > Cc: gdb@sourceware.org > > Looking at gdb docs, i couldn't find any "monitor" command or in the index. In what version of GDB did you find that manual? The current CVS version does have this command listed and indexed. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 9:29 ` Eli Zaretskii @ 2005-12-03 9:50 ` Russell Shaw 2005-12-03 9:57 ` Eli Zaretskii 0 siblings, 1 reply; 32+ messages in thread From: Russell Shaw @ 2005-12-03 9:50 UTC (permalink / raw) Cc: gdb Eli Zaretskii wrote: >>Date: Sat, 03 Dec 2005 15:44:31 +1100 >>From: Russell Shaw <rjshaw@netspace.net.au> >>Cc: gdb@sourceware.org >> >>Looking at gdb docs, i couldn't find any "monitor" command or in the index. > > In what version of GDB did you find that manual? The current CVS > version does have this command listed and indexed. Ninth Edition, for gdb version 6.2.5020041014 It was a year ago when i read it. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 9:50 ` Russell Shaw @ 2005-12-03 9:57 ` Eli Zaretskii 0 siblings, 0 replies; 32+ messages in thread From: Eli Zaretskii @ 2005-12-03 9:57 UTC (permalink / raw) To: Russell Shaw; +Cc: gdb > Date: Sat, 03 Dec 2005 20:50:21 +1100 > From: Russell Shaw <rjshaw@netspace.net.au> > Cc: gdb@sourceware.org > > > In what version of GDB did you find that manual? The current CVS > > version does have this command listed and indexed. > > Ninth Edition, for gdb version 6.2.5020041014 > > It was a year ago when i read it. Probably before I went through the entire manual and documented every command I found in the sources. Thanks. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-03 2:32 ` Daniel Jacobowitz 2005-12-03 2:41 ` Russell Shaw @ 2005-12-03 2:41 ` Bob Rossi 1 sibling, 0 replies; 32+ messages in thread From: Bob Rossi @ 2005-12-03 2:41 UTC (permalink / raw) To: Jim Blandy, Mark Kettenis, gdb On Fri, Dec 02, 2005 at 09:31:54PM -0500, Daniel Jacobowitz wrote: > On Fri, Dec 02, 2005 at 04:57:01PM -0800, Jim Blandy wrote: > > On 12/2/05, Daniel Jacobowitz <drow@false.org> wrote: > > > And every one of these things you've described doing with debuggers, > > > would require a _DIFFERENT_ plugin interface. It would be a nightmare > > > to add this to today's GDB! > > > > Oh, I figured we'd just let the plugin code #include GDB's headers > > directly, so they could get at whatever they wanted. > > > > ... okay, that does sound like a nightmare. > > Now we're communicating :-) > > For the record, here's my overall point in this thread. We have some > very good abstraction layers already: in particular, I'm talking about > the remote protocol, and the MI/interpreters mechanism. I want GDB to > be more extensible, but I believe that those protocols are the best way > to do it. They both have limitations for this kind of use, because > they aren't used that way yet; but what we need to do is commit to > using them, then bite the bullet and begin improving them to meet our > needs. > > That way we can keep the interfaces coherent, and hopefully, > documented at or above today's levels. I know my role in GDB isn't as big as most others in this thread, but for what it's worth, I fully agree with this position. Bob Rossi ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-02 18:25 [RFC] plugin/extension interface Andrew STUBBS 2005-12-02 18:49 ` Eli Zaretskii 2005-12-02 19:36 ` Mark Kettenis @ 2005-12-05 16:17 ` Andrew STUBBS 2005-12-05 16:34 ` Bob Rossi 2 siblings, 1 reply; 32+ messages in thread From: Andrew STUBBS @ 2005-12-05 16:17 UTC (permalink / raw) To: Andrew Stubbs; +Cc: GDB List Thank you for your opinions. I did not expect quite so much controversy. Rather than reply to each part of the conversation separately I shall attempt to follow up all in one message. I would have responded sooner but for the time difference. > Such suggestions (not only for GDB, for other GNU projects as well) > are usually rejected by Richard Stallman and the FSF, because they > make it possible to add to GDB significant new features with > proprietary (i.e. non-free software) shared libraries, thus avoiding > the need to release any parts of GDB under GPL. The GPL issues surprise me. I was under the impression that the GPL was harder to avoid than this. Is there anything you can point me at (an FSF judgement or whatever) that will prove that a dynamic library is not forced to use the GPL if it is linked to a GPL program (other than your assurances that this is the case)? The GPL itself mentions that system libraries are exempt, but I thought all others had to be GPL or compatible. This is an issue I would really like to understand. > It's true that plugin interfaces weaken the incentives the GPL tries > to create, but while I think that was very important even five years > ago, I don't think that's such a big deal any more. I don't really want to comment on the politics, but I think it is worth pointing out that the alternative - implementing a GDB server - does not force use of the GPL either. > GDB is a hugely complicated program, with many independent areas; it's > not clear to me which of those areas you're trying to make pluggable. > It looks to me like it is specifically the target interface - just a > very small piece of the pie. Also, new CLI commands. As you say, GDB has many interfaces. However, I cannot see any practical use for exporting many of them - GDB already supports most of what the rest of the GNU toolchain can throw at it. Perhaps some people would like it to support other toolchains, but they probably have their own debuggers. The user interface may be extended through MI, and indeed many projects do this including DDD and Eclipse, so there's not real need to do anything there (although it might be more efficient). In most respects GDB has anticipated everything it can anticipate. Of course, there are always exceptions. As I see it the thing that needs to be extendible is the target interface. Targets are one of the few areas that GDB cannot (and should not attempt to) anticipate. > If that's right, the traditional solution to the target interface is a > third party program which acts as a conversion tool between the GDB > remote protocol and your proprietary target protocol, with whatever > glue logic you would otherwise put into the plugin. The remote > protocol serves as the boundary interface in the same way that the DLL > boundary would serve as an interface. The remote protocol is very good at connecting to already-running programs, such as kgdb, uboot/redboot/etc, and gdb server. As you say, it permits custom features by means of a monitor command, but these are uni-directional and only work once connected to a target. What I propose is more of a 'local' (but not 'exec') target interface. It does not require a gdb server running already and it allows the monitor commands to be present before connecting to the target, thus allowing configuration in .gdbinit and such like. I suppose one way to look at it is this: an implementation of the remote protocol with direct function call instead of serial/ethernet and, because there is no need to arbitrarily impose the limitations of the remote protocol, a slightly friendlier monitor interface and, perhaps, access to a bit more detail. The problems I have with the remote protocol as it stands are these: a) it is inefficient when the target interface software is not actually remote; b) it is built around the idea of a ROM monitor which is not suitable for many target types - many do not exist (conceptually or actually) until the debugger causes a process to start somehow; c) the monitor commands cannot feed data or commands back into the debugger; d) the remote target cannot adjust the debugger to its configuration; e) the remote gdb server cannot access the binary, symbol table or other bits and pieces that an advanced target interface supporting profiling/trace/etc. requires. Of these a) can be fixed by having another comms flavour (such as direct function call or RPC); b) could be fixed by adding the ability to launch a process and hook up a pipe or something; and c) and d) can be fixed by extending the protocol. The other is more tricky. > 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. I had planned to add one extra file to GDB (I'm not sure that constitutes bloat). This would contain all the code to load the DLL and the implementation of the target_ops functions. Looking at it again we could unify the latter part with the remote.c code by abstracting away the actual communications somehow. I'm not convinced that nailing them together would not create more trouble than it is worth though - divergent feature sets might introduce a lot of conditional code. > All the other bits you wanted to export > as methods have less clear semantics, and some of them are guaranteed > to change over time. I certainly do not suggest that we expose any internal GDB structures. Not only would doing so make it hard to maintain plugins, they could not be compatible with multiple GDB versions. I propose that a function is added for each piece of data or action that a plugin is interested in, and no more. Each of these would be independent of the internal GDB implementation. We might have 'find_symbolname_at_address()' on the GDB side and 'objfile_has_changed()' on the plugin side. As plugin developers need access to other details they can add new methods along similar lines and their plugin (or a specific feature of it) will only work with the new version of GDB or later. If GDB no longer supports one of these (or they are thought ugly or broken) then they can be deprecated (without changing the name though) and removed as normal - plugins relying on this one feature will need fixing, but not for every new release. New ways of doing old things may be added in parallel without trouble. Obviously, all new such interfaces would go through the review process, just like any other patch. > GDB is burdened already with support for a huge > number of targets using the _one_ interface; I don't want to deal with > backwards compatibility. I'm not sure what you mean by this. I am not suggesting removing or changing the remote target in any way. Of course, to keep the number of internal interfaces down there's no reason why it couldn't be implemented as a plugin :) I'm not seriously suggesting this. > For new CLI commands, the right answer is probably to implement them > in-core in some scripting language, and optionally pass things back to > your remote target via "monitor" commands. A new scripting language would, perhaps, make this somewhat less of an issue. It is important that there is some way to configure, control and query targets with more advanced features. For example, ours supports various performance measuring, tracing and direct JTAG wiggling among other things. I would be in favour of a more integrated approach. It isn't like adding and removing CLI commands is at all difficult. > 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. This is indeed the case here. There are certain features of the targets which we use under NDA and so those parts of the code must not be open sourced. There would be no problem with the rest of the code, beyond that we prefer to keep it as a separate project with a separate code base. > I do think we will > want plugins eventually, but I haven't thought much about whether real > dlopen'd plugins are worthwhile, or e.g. python. Python plugins could certainly provide UIs or user toys, but will they ever really be able to connect GDB to a target? Would you want them to? I can't see them easily utilising many of GDB's other interfaces either. > Short term it'd only increase the load since we > have to build the plug-in interface. Long term, we still have to > maintain that interface. I am intending to build the initial plug-in interface myself, so that won't cost you anything beyond review and discussion. It will be one self-contained patch which touches very little of the rest of the debugger. Most of what it needs is already available for the use of the existing target interface and the rest of GDB in general. A few things, such as the compare section command, may need some work, but this will be quite limited. I do not intend to expose every possible aspect of GDB, nor do I think it should. If somebody needs something more later then they extend it themselves, also at no great cost to you. Maintainance is an issue of course, but such is life. > We'll also get lots of support questions > where the problems are really with the third party plugins, but where > the bug reporter conveniently forgets to mention that he's using a > third party plugin. Let's keep people out of our address space if > they don't want to commit themselves to providing sources and manpower > to maintain those sources. GDB should report errors that occur within plugins prefixed with the plugins name. That should head off most usage related issues. Of course, idiots are nothing if not cunning and will always find new ways to waste you time so I see your point. Hopefully the command names they quote would ring the alarm bells. > In other words, if the plug-ins had enough hooks to customize GDB's > behavior (printing values, or decoding the stack, say), I think you'd > be really surprised what people would do with it. They'd do tons of > stuff that we'd never want to include in the core distribution, but > which would add enormous value to GDB for their problems. And of > course, there would be a few that we'd want to incorporate. I don't have time to go that far in the initial version, but these things evolve and I'd be happy to make the start and do targets and commands. As I hinted above, there's no point implementing something, in an open source project, on the off chance someone will use it. You put in the core bits and let people extend it as they need to. As I think somebody else said, the frontend stuff can be done other ways. I'm more interested in backend stuff (which has a frontend presence). > I'm already in the long process of creating a level on top of GDB > using MI that allows another process to do anything it wants with GDB. Can it add target interfaces? Efficiently? > Oh, I figured we'd just let the plugin code #include GDB's headers > directly, so they could get at whatever they wanted. No, that would be just nasty. > ... okay, that does sound like a nightmare. Agreed, if you tried to take it too far. > I did it to replace the current hack of having an extra program on the > pc that converts between the default gdb target protocol, and this > ICE-specific protocol. > The conversion hack was extremely slow, clumsy, fault-intolerant, and > error-prone. > With the specific interface in gdb, the performance was wonderful, and > new gdb commands can be easily registered for this ICE, that are only > accessible after the command "target avrjtagice -d /dev/ttyS2" is > performed (like an emacs minor mode or whatever). So there's at least two (groups) of us have gone through exactly the same process. How many others I wonder? I think the rest of the discussion was mostly about GDB internals and documentation. If I have missed any important points that needed an answer then I apologise. Andrew Stubbs ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [RFC] plugin/extension interface 2005-12-05 16:17 ` Andrew STUBBS @ 2005-12-05 16:34 ` Bob Rossi 0 siblings, 0 replies; 32+ messages in thread From: Bob Rossi @ 2005-12-05 16:34 UTC (permalink / raw) To: Andrew STUBBS; +Cc: GDB List > > I'm already in the long process of creating a level on top of GDB > > using MI that allows another process to do anything it wants with GDB. > > Can it add target interfaces? Efficiently? Andrew, I personally think the approach you took to responding is very confusing. I feel like I'm flipping through chapters of a presedential debate, and reading random paragraphs. Others may feel different, but if I were you, I'd respond traditionally. As far as your question, the answer is no. You would have to extend MI to be able to add target interfaces efficiently, which would be similar to extending the CLI. What I am working on, will simply give your program access to the MI layer, efficently and correctly. Bob Rossi ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2005-12-05 16:34 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-12-02 18:25 [RFC] plugin/extension interface Andrew STUBBS 2005-12-02 18:49 ` Eli Zaretskii 2005-12-02 19:23 ` Daniel Jacobowitz 2005-12-02 19:36 ` Mark Kettenis 2005-12-02 22:12 ` Jim Blandy 2005-12-02 22:16 ` Daniel Jacobowitz 2005-12-02 22:41 ` Mark Kettenis 2005-12-02 23:07 ` Jim Blandy 2005-12-02 23:13 ` Bob Rossi 2005-12-02 23:32 ` Daniel Jacobowitz 2005-12-03 0:57 ` Jim Blandy 2005-12-03 2:32 ` Daniel Jacobowitz 2005-12-03 2:41 ` Russell Shaw 2005-12-03 2:45 ` Daniel Jacobowitz 2005-12-03 3:13 ` Russell Shaw 2005-12-03 3:33 ` Daniel Jacobowitz 2005-12-03 4:05 ` Russell Shaw 2005-12-03 4:14 ` Daniel Jacobowitz 2005-12-03 4:44 ` Russell Shaw 2005-12-03 4:49 ` Daniel Jacobowitz 2005-12-03 5:25 ` Russell Shaw 2005-12-03 12:49 ` [commit] Clarify "monitor" command (was: [RFC] plugin/extension interface) Eli Zaretskii 2005-12-03 12:51 ` [commit] Clarify "monitor" command Russell Shaw 2005-12-03 16:08 ` [commit] Clarify "monitor" command (was: [RFC] plugin/extension interface) Daniel Jacobowitz 2005-12-03 5:06 ` [RFC] plugin/extension interface Russell Shaw 2005-12-03 5:12 ` Daniel Jacobowitz 2005-12-03 9:29 ` Eli Zaretskii 2005-12-03 9:50 ` Russell Shaw 2005-12-03 9:57 ` Eli Zaretskii 2005-12-03 2:41 ` Bob Rossi 2005-12-05 16:17 ` Andrew STUBBS 2005-12-05 16:34 ` Bob Rossi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).