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
- 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?
- 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?
- What is the
plan of getting this is CDT – is there attached patch we can look
at?
Breakpoint extensions
- 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?
- 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
