[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Integrate custom debugger to visualize debug-session
|
The things I mentioned all implement the platform debug APIs at one level or another, and already provide all of the visualization aspects for you. So you merely need to somehow connect your existing debug server to one of those. For example, with TCF Debug you could add your OMF parser to the symbols service, and hook up memory, registers, run control, etc as services in C/C++. That TCF agent can run on your computer or on a remote device. In your case it sounds like it would be running on your computer. The Eclipse side of TCF will communicate with it over TCP/IP and handle all visualization for you. For getting started with TCF you can look here: http://git.eclipse.org/c/tcf/org.eclipse.tcf.git/plain/docs/TCF%20Getting%20Started.html
You can install TCF into your development Eclipse via Help->Install New Software. You can checkout the TCF agent project from http://git.eclipse.org/c/tcf/org.eclipse.tcf.agent.git. You can build it with CDT or Visual Studio it looks like. I don't know exactly where you need to hookup your debugger but it would mostly be scattered through \tcf.agent\agent\tcf\services\. It's probably well documented somewhere. Hopefully someone more familiar with that project can comment.
If you went with EDC you'd still have a TCF agent and implement low level services in C/C++ at that level. You'd also add Eclipse plugins to extend EDC to support your target architecture and debug symbols format. Basically you'd add your OMF parser and a disassembler for 8051 which also indicates instructions can modify the PC for the generic stepping logic.
Another option would be something like making your debug server speak gdb/mi, and use gdb and the existing DSF/GDB integration. I don't believe this will work though as GDB doesn't understand OMF AFAIK, and you can't parse the symbols on the MI side of things. I'm as far from a GDB expert as you can get though so anyone can correct me if I'm wrong.
Finally, you could bypass all existing debuggers and hookup to the platform debug API directly, but I think that going to much more work.
Thanks,
Warren
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan.Falk@xxxxxxxxxxxx
Sent: Thursday, August 22, 2013 2:46 AM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Integrate custom debugger to visualize debug-session
Hi Paul and thanks again for your answer!
The integration points you were speaking about (CDT CDI, CDT DSF etc.) do provide an interface for visualization?
As I mentioned I tried it like this:
http://www.eclipse.org/articles/Article-Debugger/how-to.html#Breakpoints
and got it running so far. Truly it's a bit of a simplification at this point but I'm just a Eclipse Plug-in Developer beginner that tries to manage a quite huge task as it turns out. :P
I'm sorry if you already answered this but somehow I still can't imagine or think of any way how to integrate with the Eclipse platform debug API. I am very sure that there is one but so far I did not stumble upon anything that could help me.
I took a look on TCF. Are you sure this is what I would need? I already communicate with my debug target via a Java .NET bridge which works great.
May it possible that my following assumption is the problem here:
Let's say I got the complete Debug-Process wrapped and managed in another program - So Eclipse really would only have to manage the UI part. In my assumption there is something like this fancy Debug Model but just for visualization part. So the debug part is completely separated from anything UI related. But I already have the feeling - like you said - that I simplify the problem too much, right?
Thanks again and again! :)
Stefan
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Warren Paul
Sent: Wednesday, August 21, 2013 1:59 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Integrate custom debugger to visualize debug-session
Hi Stefan,
I'm afraid you may be oversimplifying it a bit. Somehow you need to integrate with the Eclipse platform debug API's. You can either do so directly, or you can do so at a different level. CDT CDI (deprecated), CDT DSF, CDT EDC and TCF Debug have already done this for you, and each has a different integration point. If you want to do it directly then take a look at this article: http://www.eclipse.org/articles/Article-Debugger/how-to.html. It's old but I believe still more or less relevant. Either way it's a non-trivial task. IMHO you're better off using an existing CDT or TCF integration. More of the work is done for you, and you get other native debug support like register/memory access and disassembly.
My guess is that TCF Debug would be the quickest route for you to get something working. You basically need to add your OMF parser to the TCF C source and build that into a local or remote executable. You also need to glue the various TCF services to your debug adapter/part. I'm sure there's some references online somewhere.
Thanks,
Warren
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan.Falk@xxxxxxxxxxxx
Sent: Wednesday, August 21, 2013 3:00 AM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Integrate custom debugger to visualize debug-session
Hi Paul :)
Thanks again for your answer! You pretty much described the process I've been through! :D
I already wrote a (at the moment very simple) parser. It is possible to associate an address of the instruction pointer with a C-Line.
One of my problems - which is a really essential one - actually is to integrate my already pretty much working debug session into the UI from Eclipse. This is the one and only thread that at the moment debugs the program on the 8051
private class DebuggerThread extends Thread {
@Override
public synchronized void run() {
while (isTerminated() == false) {
try {
while (program.isSuspended() == true) {
wait();
}
program.resume();
program.suspend();
} catch (DebugException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
When the users clicks "single step" the thread wakes up and the program resumes. After return the program gets suspended and the actual thread waits again for a "single step" instruction by the user via Eclipse GUI.
Resume() looks like this:
@Override
public void resume() throws DebugException {
if (breakpointsAddr == null) {
breakpointsAddr = new int[] { 0x0 };
}
controller.RunUntil(breakpointsAddr);
System.out.println("Stopped at " + Integer.toHexString(controller.readPc()));
}
I think this is almost self explanatory? Program.resume() tells the SP40-processor to run until it hits a breakpoint - this works.
Program has a map that stores Map<InstructionPointer, C-Line>.
But I just don't find the right place where to start with the actual visualization of this. Like I said, I would not want to re-invent things that the is already CDT Plugin able to.
The Debug Model already supports and automates a few visualization parts but I don't want to get into this right now.
The point is, that I don't even know that method/function that would highlight e.g. one specific line.
Thank you for your help! :)
Best regards,
Stefan
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Warren Paul
Sent: Tuesday, August 20, 2013 3:50 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Integrate custom debugger to visualize debug-session
HI Stefan,
It sounds like what you're lacking is an OMF parser. I believe SDCC generates an OMF binary which contains executable/debug information. Something needs to parse the debug information to let the debugger know what file/line match a given address. How/where that's hooked up to the debugger depends on which debugger implementation you choose.
A word of caution though - OMF is an archaic format. I believe it does support line information (source/line/address mapping), but it does NOT support variables or types. So while you might be able to visualize the source, you won't have a complete GUI debug experience.
Other things to consider if you're able to get that far:
When you do have source correspondence, you probably want to support source-level stepping (as opposed to just single instruction stepping). That's the default step mode when there is source associated with the PC. Ideally you determine how many instructions were generated for that given source line, parse them, and figure out how to step to the end of those instructions, keeping step in vs. over in mind. Often times that takes temporary breakpoints, and you're probably limited to just 4 total breakpoints on 8051.
In order to provide the above you'll need a disassembler. If you have one you can use it to populate the disassembly view and even interleave the instructions with the matching source code. Thankfully this isn't too hard given there are only 255 instructions in 8051.
If you were to add an OMF parser, where you add it is determined by which debugger you're using. Symbol parsing, disassembly and stepping logic is usually done in GDB itself I believe, while things like run control and memory access are done in the GDB stub layer. Someone more familiar with GDB can correct me if I'm wrong. In EDC, those things are in done in the EDC layer in Java, while the lower level debug control is done in the TCF layer. In TCF Debug pretty much everything is done in the TCF layer.
I hope this helps.
Thanks,
Warren
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan.Falk@xxxxxxxxxxxx
Sent: Tuesday, August 20, 2013 2:28 AM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Integrate custom debugger to visualize debug-session
Hi Paul! Hi all!
Thank you for your detailed answer!
I am not quite sure if the EDC is what I need. Like I said, all I would need at this point was an easy access to the Eclipse UI such that I can visualize the debug process.
You were right, I want to debug a 8051 based processor. For that purpose there is a server running which is communicating with the processor. This server also works as debug interface. I can retrieve all necessary debug-information (register values, ..) and allows me to single step or set breakpoints etc.
I already have a "working" debug session running in Eclipse. The part where I am failing is visualizing that e.g. in file:main.c line:50 the current instruction is executed and should be highlighted.
Maybe I'm missing something but basically all I am looking for is functionality like:
int pc = getProgramCounter();
File f = getCurrentlyExecutedFile();
System.out.println("Program is in file: " + f.getFilename() + " in line " + f.getCurrentlyExecutedLine());
myEditor.highlichtLine(f);
And therefore I'd like to use that functionality the CDT Plugin should already support.
Under "Window > Prefences > General > Editors > Text Editors > Annotations" there is an annotation called "Debug CurrentInstruction Pointer"
Like there are a few different debug-models there should be at least one model that allows you to visualize that process. Otherwise I would have to re-invent the wheel..
Please advise me if I misunderstood something here.
Thank you!
Best regards; Stefan
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Warren Paul
Sent: Monday, August 19, 2013 5:35 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Integrate custom debugger to visualize debug-session
Hi Stefan,
I take it you're creating an 8051 debugger given that you're working with the sdcc toolchain. I was in the same exact boat about a year ago. Here are the options I explored at the time:
1) Add 8051 support to GDB and use the existing DSF/GDB support in CDT.
2) Create a new DSF debugger based on the GDB reference implementation.
3) Use TCF Debug
4) Use EDC
I'm pretty sure these are still your same options.
I didn't want anything to do with #1 for various reasons I won't go into here.
#2 is not a bad option, but is quite a bit of work.
I looked hard at #3, but IMHO it just wasn't quite there yet. It seemed to be active, but there was just a lack of full integration of the various debug views.
We went with #4 for a number of reasons. First of all EDC was contributed by my old team at Nokia, so we had a lot of experience/familiarity with it. It still uses TCF, so there is some C/C++, but the majority of code is written in Java which I prefer. It's easier to write and has a better debug experience with hot swapping, etc. I knew EDC was fully integrated with all of the debugger UI, more so than TCF Debug, at least at that time. We also needed an ARM debugger. EDC already had an ARM debugger that was used widely at Nokia so we got that more or less for free. I don't think TCF Debug had ARM support at the time, though I think they probably do now.
I actually just looked to see if I could find my old notes on this, and I was able to:
TCF-DEBUG PROS:
Uses standard platform debug views (not asynchronous) so it's simpler Still active project
TCF-DEBUG CONS:
Almost everything is in the agent side and therefore C code It's harder to work in that project because everything is ifdef'ed so keeping in sync becomes problematic We'd have to redo the launch stuff ourselves, launching our own local TCF agent automatically (like we did in EDC).
It's incomplete. No disassembly service. What else?
The quality level is unknown at this point
EDC PROS:
Mostly Java
Easy to identify where we need to add 8051 support and it's pluggable (no ifdef's) It is feature complete and then some:
Common stepping logic
Source lookups
Expression parser
Scripting
Variable formatting
Snapshots
Disassembler framework
Breakpoint actions
Launch support
EDC CONS:
Nobody else is currently using it
It may be overkill - asynchronous views bring complexity
I'm not trying to steer you in any direction. I'm just laying out what your options might be. In any case you'll probably want/need an OMF parser, an 8051 disassembler and glue code from whatever debug API to your existing debugger for things like run control, memory/register access, etc.
I hope this helps.
Thanks,
Warren
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan.Falk@xxxxxxxxxxxx
Sent: Monday, August 19, 2013 2:41 AM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Integrate custom debugger to visualize debug-session
Hello Marc!
Thank you for your answer!
So I think the best thing I could do is to get the DSF-GDB source code and modify it to my needs, right?
I assume that there will be some fundamental changes necessary - but if this still can save me some time I think I'll give it a try.
Thank you very much and best regards,
Stefan
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
Sent: Wednesday, August 14, 2013 4:40 PM
To: 'CDT General developers list.'
Subject: Re: [cdt-dev] Integrate custom debugger to visualize debug-session
Hi Stefan,
I'm afraid I can be of much help as my experience has always been DSF, so I cannot compare with the standard debug model.
Maybe someone else who has extended CDT debug can share their experience with respect to the following questions:
> - What would be the easiest and most reusing way to visualize my
> debugging session in Eclipse which would include at least "highlight
> current instruction", "display register contents"
> and (maybe) visualize the stack trace. Is there a way to reuse parts
> of the CDT Plug-in?
Usually, people extend the existing code. If you use GDB, the extension can prove small, but if you are not, it will be more work.
> - Should I stay to the standard debug model which is used in the
> article [1] or should I take a closer look on the CDT-DSF model?
>
> - Can anyone recommend me a good code example which I could download?
The DSF-GDB integration is the best example you'll find or the CDI-GDB one for the standard debug model.
There is the EDC debugger that uses DSF and I believe there is a smaller example called PDA which uses DSF which you can find in
org.eclipse.cdt.examples.dsf.pda
org.eclipse.cdt.examples.dsf.pda.ui
I hope this helps.
Marc
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Stefan.Falk@xxxxxxxxxxxx
> Sent: Tuesday, August 13, 2013 7:38 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] Integrate custom debugger to visualize
> debug-session
>
> Hey guys!
>
> I've been struggling with this a few days now and I really hope that
> someone can help me here and maybe takes a few minutes to give me a
> few pushes into the right direction!
>
> Here is what I got:
>
> I got an object MDevice that represents a controller which program I
> want to debug. I already can single-step, run to breakpoints and all
> that stuff I would want to do with a debugger. I am also already able
> to resolve the program counter address to a specific line inside the
> source code.
> Needless to say that I can read out the registers and all that stuff
> too. All that works on a satisfying basis so this end does not need to
> be minded.
>
> The whole source code is written in C and I am using a naked Eclipse
> Application plus the CDT Plug-in and another Plug-in called the
> "eclipseSDCC" (Plug-in for the compiler I'm using).
>
> Here is what I want to do:
>
> Now I want to visualize the debugging process - and of course
> - use as much of the CDT Plug-in as possible since I don't want to
> reinvent the wheel a dozens of times. I found the "How to write an
> Eclipse debugger" [1] and implemented the model so far but I struggle
> on such basic things like "highlighting the current instruction the
> instruction pointer refers to". Then I found this conversation [2]
> about the CDT-DSF which I took a look at too.
>
> This leads me to the following questions:
>
> - What would be the easiest and most reusing way to visualize my
> debugging session in Eclipse which would include at least "highlight
> current instruction", "display register contents"
> and (maybe) visualize the stack trace. Is there a way to reuse parts
> of the CDT Plug-in?
>
> - Should I stay to the standard debug model which is used in the
> article [1] or should I take a closer look on the CDT-DSF model?
>
> - Can anyone recommend me a good code example which I could download?
>
> Thank you for any help. I'm really stuck here for days now even though
> I thought setting up the communication to my device I'd like to debug
> would be the much harder part.
>
> Thank you for any help!
>
> Best regards, Stefan.
>
> [1] http://www.eclipse.org/articles/Article-Debugger/how-to.html
> [2] http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg26119.html
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.
Thank you.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.
Thank you.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.
Thank you.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.
Thank you.
