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

This has been a great discussion and I look forward to it continuing. I think there are two use cases here and I think it should be possible to solve both, maybe with some common code.

 

One use case is really just to use the CDT as a GUI front end to the debugger. The user doesn’t want to know about projects and does very little source navigation. They just want to use the CDT as they do DDD, a common GUI front end for GDB. We can call this project-less debug. (I think the RCP version of this is what we were calling standalone debug that Oyvind was working on turns out to be the same).

 

The second is someone who wants to do a little more source navigation and set up breakpoints before launching the debugger. I like Ken’s term of build-less projects. My hope here is that we can get the CDT’s source navigation features, like open declaration, search, etc., i.e. the infamous indexer, working with these projects as well.

 

The end goal is to lower the barrier to entry to the CDT by making it more useful for more tasks than the traditional edit/build/debug cycle. I love where you guys are taking this and encourage you to keep both paths open.

 

Cheers,

Doug

 

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