| Re: [cdt-dev] Hooking into GDB/MI |
|
> One quirk is that the reply objects *Info cannot be created directly, but have to
> be constructed from MI output. I have to admit that those classes were not written with your use-case in mind. However, you can probably work around that pretty easily. Each method to extract information from the *Info classes is public, therefore overridable. What you can do is extend each class in question that you need and override the getter methods to return the value you want. Your new extended method can provide the constructor that the base class is missing. e.g., public class MyMIVarInfoTypeInfo extends MIVarInfoTypeInfo { String fType; MIVarInfoTypeInfo(String type) { fType = type; } @Override public String getType() { return type; } } From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Jesper Eskilson [jesper.eskilson@xxxxxxx]
Sent: March 22, 2016 9:52 AM To: cdt-dev@xxxxxxxxxxx Subject: Re: [cdt-dev] Hooking into GDB/MI On 2016-03-18 11:55, Marc Khouzam 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. 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. Ok, thanks. Good to know that the idea isn't completly futile. It looks like the easiest way for us is to override queueCommand, and have it return "synthetic" objects (MIInfo + subclasses). One quirk is that the reply objects *Info cannot be created directly, but have to be constructed from MI output. I can create MIOutput objects which "mimic" the expected response from GDB, but it would've been nice to be able to create the *Info objects directly. I was considering parsing the raw MI stream, but I'd like to avoid having to maintain my own MI parser. :) /Jesper 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 --
Jesper Eskilson Development Engineer IAR Systems AB |