Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


Back to the top