A note about a GDB BoF topic - libgdbserver

A note about a GDB BoF topic - libgdbserver

[Pedro Alves]

Hi,

On the GDB BoF @ LPC this week [1], we discussed the possibility
of splitting gdbserver's core bits into a library so that
other projects like valgrind, embedded stubs, simulators, 
etc. could reuse it.

Licensing issues aside, the trouble as always is, who is
going to do the work, is there someone motivated to do it?

One thought that crossed my mind afterwards is a desire to
change how GDB supports the sim.  Instead of gdb's sim support
being implemented by gdb linking with libsim.a, it would be
better if we made the sim a separate gdbserver-like program that 
communicates with GDB via the remote protocol.  That would allow
for example connecting to multiple simulators at the same time,
even different simulators of different architectures at the
same time.

That seems like a good excuse to move in the libgdbserver
direction, and it doesn't even require thinking about
licensing.

Of course, another option would be to make gdbserver itself
link with libsim.a -- make the sim another gdbserver backend.
But that doesn't sound as cool.  ;-)

[1] https://www.youtube.com/watch?v=mMwC0QenvcA

Re: A note about a GDB BoF topic - libgdbserver

[Tom Tromey]

Pedro> Of course, another option would be to make gdbserver itself
Pedro> link with libsim.a -- make the sim another gdbserver backend.
Pedro> But that doesn't sound as cool.  ;-)

I looked into this a bit, since I was curious what it would take to make
gdb require target async.

My thought was to have a sort of "libgdbserver" -- basically consisting
of all the non-"target low" files in gdbserver.  Then, write a new low
target somewhere in sim/.

This seemed doable enough, but a bit of a pain as well.  Testing the
sims seems hard, at least for someone like me who isn't up on the
details of the linker scripts to use etc.

Another issue is that gdb lets the sims define a non-standard register
layout.  Maybe this could be reverse-engineered into an XML file that
would be served by the sim.  Or, maybe the sims could be changed to use
gdb's built-in register layout.

Anyway, the main problem is that it looks like a reasonably large amount
of work, but where the impact is low.  This seems especially true since
IIUC, gdb requires even async-capable targets to still support leaving
async mode at times.

Tom