Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-debug-dev] Re: Debugging executables with no project
Title: Re: [cdt-debug-dev] Re: Debugging executables with no project

To further explain what Dobrin is relating…

 

Some of our customers code entirely in assembly.  The have a device already running (perhaps out in the field) that is for some reason misbehaving.  The want to connect to it live and debug it, and in many cases they couldn’t load an executable onto it even if they wanted to because the program code is in ROM.  Since the program is entirely assembly they don’t want to bother setting up any source browsing because they don’t really need it.  The disassembly provides all they need because for their purposes it’s the same as the original assembly source.  They might or might not want to load symbols into the debugger to make their lives easier debugging the disasm.

 

I think there is a use case as well for people that *could* go grab original C-sources or whatever, but just don’t want to.  For some die hards, the disassembly is all they need.

 

For the most part I think Ken is right though, a dummy project wouldn’t typically get in the way.  There would always be users that will get confused about its existence though, so it would be nice if it didn’t have to be created if the actual debugging didn’t require it.  I don’t think it’s a killer though and I think Ken’s idea is a good start.

 

___________________________________________

 

Chris Recoskie

Software Designer

Texas Instruments, Toronto

http://eclipse.org/cdt

 

 

From: cdt-debug-dev-bounces@xxxxxxxxxxx [mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Alexiev, Dobrin
Sent: Thursday, November 17, 2005 12:13 PM
To: CDT Debug developers list
Subject: RE: [cdt-debug-dev] Re: Debugging executables with no project

 

Thanks Ken for you feedback.

I am looking forward to see you work integrated in CDT.

 

One of the reasons a project-less debugging may be a priority for us because some of our user tasks are not so much source or assembly debugging but more like monitoring register or memory and running and halting the target. If we abstract the access to the target as CDT Debug Target that will let us create specialized plug-ins that use the CDI model to solve higher level tasks.

 

Anyway, if that is not a big effort, may be it is worth doing it. I still think that in some cases we are trying to make a workaround because of limitations, instead of fixing the limitations. I don’t know. If many other IDEs have it as concept, may be it will be yet another way of making our user’s live easier in the Eclipse and CDT world.

 

About a breakpoint executing a script: Is may be worth putting something like that in CDT. Most of the commercial IDE have its own scripting and I think it is worth generalizing in at CDI level. I don’t know if GDB has this feature or not.

 

Regards

Dobrin

 

From: cdt-debug-dev-bounces@xxxxxxxxxxx [mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Ken Ryall
Sent: Wednesday, November 16, 2005 8:50 PM
To: CDT Debug developers list
Subject: Re: [cdt-debug-dev] Re: Debugging executables with no project

 

Dobrin,

Thanks for the feedback. Here are some notes on your notes:

I noticed that making a really project-less debugging is not considered. What are the real problems with that? I was going to investigate that too because we have use cases in which the user just want to do low level debugging – stepping in assembly, stack frame with only assembly addresses, opening register and memory windows, having the console connected so they can control the debugging and do Std IO operations. None of these require OUT file or source files debugging. I was about to investigate what are the current limitations in CDT to achieve this but after I saw your comments looks like you already have done some investigation. Is it something with the platform that has to change or it is only CDT? Is anyone interested in achieving real project-less debugging?

I don’t think there is a clear benefit to going completely project-less and several benefits to having a debug project around. My initial approach was to do project-less debugging. I even disconnected a bunch of the places where CDT wants a project reference etc. I backed off because I concluded that while you obviously want to debug without having to make a project that builds things, having a project that organizes a debug session is not inherently evil and can be quite useful. If you do have source to work with you’ll want to be able to browse the files referenced by the symbol table and set breakpoints etc in them. If you don’t have any source then the debug project can still be used to organize groups of executables along with any other associated files. If your debug scenario doesn’t require any of those things then a debug project just sits there and doesn’t bother anyone. I think that when people ask for project-less debugging they want to be able to attack their problem with as few steps as possible and have unrelated tools get out of the way. I don’t think we have to completely toss the project concept out to satisfy them or to have a debugging environment that can cleanly support low level debugging scenarios.

How does this integrate with different CDI debuggers? We are in a process of making our backend a CDI debugger and we have our launch type, lunch delegate, CDebugger, etc. Will you implementation hook up with a non GDB debuggers nicely? You mentioned that the last step of the debugger is creating a launch configuration. Is that configurable - can the user create our debugger’s launch configuration?

Our debugger is not GDB and is integrated at the CDI level so I can’t think of any reason you would have issues. Both the Import Executable Wizard and launch configuration creation process is extensible and configurable. You can add additional stuff to the wizard and customize the launch configuration all you like. We’re doing this in our product and creating a launch that’s specific to our debugger.

What is the plan of getting this is CDT – is there attached patch we can look at?

We’re shipping this as part of our product in January and would like to get it into CDT soon afterward. There is no attached patch yet but I hope to overcome some logistical hurdles and provide one in a few weeks for review.

For the advanced breakpoint you mentioned that one action is to execute a script. What scrip is that? Is it backend script only or it is something more generic? How will this fits with CDT?

Sorry, the script action is really just firing off a process that could be anything (perl script etc.) I should have left it our of the examples as it is such a loaded term.

What are the plans for making the implementation of the advanced breakpoints available?

They are not as far along but we should have something to share in Q1 2006.

Thanks - Ken

From: "Alexiev, Dobrin" <dalexiev@xxxxxx>
Reply-To: CDT Debug developers list <cdt-debug-dev@xxxxxxxxxxx>
Date: Wed, 16 Nov 2005 16:49:51 -0600
To: <cdt-debug-dev@xxxxxxxxxxx>
Conversation: Re: Debugging executables with no project
Subject: [cdt-debug-dev] Re: Debugging executables with no project

Hi Ken,
Great job! I really like your proposal.
We were just about to start doing something similar and I am so glad that you are already done it and you are working with CDT to get it in the main stream.
Here are my notes for the project-less proposal and the advanced breakpoints you mentioned in the power point slides:
Project-less debugging

  1. I noticed that making a really project-less debugging is not considered. What are the real problems with that? I was going to investigate that too because we have use cases in which the user just want to do low level debugging – stepping in assembly, stack frame with only assembly addresses, opening register and memory windows, having the console connected so they can control the debugging and do Std IO operations. None of these require OUT file or source files debugging. I was about to investigate what are the current limitations in CDT to achieve this but after I saw your comments looks like you already have done some investigation. Is it something with the platform that has to change or it is only CDT? Is anyone interested in achieving real project-less debugging?
  2. How does this integrate with different CDI debuggers? We are in a process of making our backend a CDI debugger and we have our launch type, lunch delegate, CDebugger, etc. Will you implementation hook up with a non GDB debuggers nicely? You mentioned that the last step of the debugger is creating a launch configuration. Is that configurable - can the user create our debugger’s launch configuration?
  3. What is the plan of getting this is CDT – is there attached patch we can look at?

Breakpoint extensions  

  1. For the advanced breakpoint you mentioned that one action is to execute a script. What scrip is that? Is it backend script only or it is something more generic? How will this fits with CDT?
  2. What are the plans for making the implementation of the advanced breakpoints available?

Regards
Dobrin Alexiev
Texas Instruments

Title: Debugging executables with no project

Hi,

At the recent CDT Contributors Summit I presented a proposal for some additions to let you easily debug executables even if you don't have a project that builds them.

Doug had posted the slides here:

http://download.eclipse.org/tools/cdt/docs/summit2005/Debugger_Features.ppt

and I've just attached a more detailed description of our proposal to:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=39640

Please take a look and send me any feedback, comments, or questions.

Thanks,

Ken Ryall
Nokia Developer Platform Tools

_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

Back to the top