Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Hooking into GDB/MI

Hi Jesper,

We've done similar things for clients in the past, i.e. disguised debuggers using DSF-GDB. 

In our experience it works quite well, but one thing to be aware of is the whole 'context' issue (IDMContext). 
For starters, different version of GDB have different behaviour with regard to contexts. So for example in GDB 7.4 the context for a breakpoint being set is for all inferiors at once. 
Previous versions (pre 7.4) have different behaviour (e.g set breakpoint per process), and I believe future versions will be different yet again, so decide which one is closest to your debugger or rewrite if necessary. 

In one case we needed the debugger to support the ability to set breakpoints per core for specific multiprocessor solutions. This ended up meaning implementing our own contexts and equivalents to GDBProcesses. 
It was more work than we expected at the outset, but still overall better to take advantage of other logic/features of DSF as you describe. 


On Fri, Mar 18, 2016 at 10:55 AM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
Hi Jesper,

my first reaction is that I like your idea.  I don't know how difficult it will be to map MI commands to something that will make sense to your debugger, so the effort is hard to judge.  But if you can make it work, I feel you would benefit from all the work that continues to be put into DSF-GDB.  Not to mention that we would benefit from you also being part of that effort :)

Here are some things to think about.

- You have to deal with both input and output of DSF-GDB. has two threads, one to receive, one to send.  As you already know sending happens through queueCommand().  Receiving happens in that same class in processMIOutput().

- If you intercept outgoing MI commands, you will still need to parse them and convert them to your debugger format.  And when you receive your debugger's reply, you will need to generate a properly-formatted MI answer to match the original MI request.  So it sounds like you will still need to effectively implement MI for your debugger; it could be in Eclipse as you suggest, or on your debugger side, or as something in between; but I don't think you'll be able to avoid doing an MI translator.

- MI provides asynchronous events to notify front ends of things such as a thread hitting a breakpoint.  DSF-GDB needs those events; your debugger will need to provide something similar.

- You will have to handle, hopefully in a catch-all way, any MI commands that comes in that you didn't expect.  When a new feature is added to DSF-GDB, you need to make sure any new MI command won't break your implementation.

lldb has done it with lldb-mi and it allowed to very easily make it work with CDT, so the history is on your side.

Good luck.


From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Jesper Eskilson [Jesper.Eskilson@xxxxxxx]
Sent: March 17, 2016 4:27 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Hooking into GDB/MI


As some of you know, we have a debugger (C-SPY) for which we have a DSF-implementation which does not use GDB. We have implemented our own set of DSF services, and this has worked fairly well over the last few years.

Inspired by the CDT hackathon, I wanted to take a stab at an idea I've had for a while, namely to "disguise" our debugger as GDB. The purpose would be to avoid having our own implementation of some rather hairy DSF service logic and also to be able to be in a better position to contribute code to DSF/GDB as well as leverage from new features being implemented in DSF/GDB.

After doing some research on GDB/MI I realized that it would be nice if we could avoid having to reimplement the GDB/MI wire protocol. Since the MI commands are nicely queued by the GdbControl service, I thought that one might be able to intercept them in e.g. queueCommand(). Each MI command would then need to be "interpreted" to interact with our debugger.

Before really digging any deeper into the intricacies of the DSF/GDB/MI internals, I thought I'd post an open question here about this. Does this seem like a reasonable idea? Or should we stay with our own DSF implementation?


Jesper Eskilson Developer
IAR Systems AB

cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top