This is the mail archive of the gdb@sourceware.org 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]
Other format: [Raw text]

[RFC] plugin/extension interface


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


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