| Re: [cdt-dev] Hooking into GDB/MI |
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. AbstractMIControl.java 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.
Marc
________________________________________
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
_______________________________________________
Hi,
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?
Cheers,
/Jesper
--
Jesper Eskilson Developer
IAR Systems AB
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev