[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Debugger Source File Lookup
|
I don't use the Debug As... approach. I just create a runtime-workbench
launch configuration by going to Run > Debug Configurations, then
double clicking on Eclipse Application. That creates a new launch config
that I then use from that point on whenever I need to debug a plugin. Try
that approach and see if it make a difference.
John
At 05:08 PM 3/18/2010, Tim Black wrote:
Not hitting any of the above
breakpoints yet...
Does it matter whether I set the breakpoints before doing Debug As -
Eclipse Application?
For the purposes of trying to simply hit a breakpoint in
getSourceElement(Object element) does it matter whether I select one or
several of the org.eclipse.cdt.* plugins in my workspace before right
clicking and using Debug As.. .Eclipse Application?
I am setting the breakpoint by double clicking in the far left column of
the .java file editor.
On Thu, Mar 18, 2010 at 2:48 PM, Andrew Gvozdev
<angvoz.dev@xxxxxxxxx>
wrote:
- Try CommonBuilder.build() method which extends
IncrementalProjectBuilder#build (in
org.eclipse.cdt.managedbuilder.internal.core)
- Andrew
- On Thu, Mar 18, 2010 at 5:40 PM, Tim Black
<timblaktu@xxxxxxxxx>
wrote:
- I have made a few changes to the layout and makefiles of my simple
project and it still succeeds. I would like to follow your suggestion to
debug it, but...
- I'm having trouble breaking at a breakpoint while debugging CDT. I'm
using 3.5.2 Eclipse SDK and have all CDT_6_0_2 plugins in my workspace
and built. I put a breakpoint in invokeMake() in
org.eclipse.cdt.make.core/src/org/eclipse/cdt/make/core/MakeBuilder.java.
I launch the eclipse application by selecting all plugins in my workspace
and do "Debug As" - Eclipse Application. I import a makefile
project in the resulting eclipse, and build it, but I do not hit my
breakpoint. Is there a better place to put a breakpoint where I will be
sure to hit it to prove that I am debugging properly?
- On Thu, Mar 18, 2010 at 1:50 PM, John Cortell
<rat042@xxxxxxxxxxxxx>
wrote:
- At 02:43 PM 3/18/2010, Tim Black
wrote:
- I don't understand how you could have this problem. Can you try to
reproduce it with a simple project using stock CDT?
- I don't either. I'm not the only one that's reported this problem
(see link in my last post). I just failed to reproduce it in a very
simple makefile project like this:
- 2mains/a/main.cpp
- 2mains/b/main.cpp
- 2mains/makefile
- The makefile just builds b/main.cpp. When I debug this, it breaks in
the correct place, b/main.cpp. My project has many more subprojects, each
with their own makefiles that get invoked by the top level makefile. I am
currently using the CDT bundled with Galileo.
- That's what I was afraid of. I tried this sort of thing just recently
and it worked for me. We'll need a reproducible case in order to figure
out if this is a bug or some sort of configuration error.
- When the debugger looks for a file, it does so by using source
locators. The source locators used for a debug session are the ones in
the launch configuration (and any defined in the global preferences). The
Absolute File Path is a locator which finds the file by looking for it at
exactly the location specified in the specification. So if the
specification is an absolute path, that locator looks for it at exactly
that location.
- So the "Absolute File Path" locator looks for files using
an absolute path, and the Project locator looks for files relative to the
project root? This seems straightforward.
- The project container (locator isn't the precise term; my bad) is
really just a composite container that is made up of folder
containers--specifically a tree of them, which reflect the folder
directory in the project. Each folder container searches based on the
given string file specification. This type of container comes from the
platform (not CDT), and you can discover the search behavior by looking
at ContainerSourceContainer.findSourceElements(String). It will work if
the file specification is a simple filename or a relative one, but this
type of container will not work if the specification is an absolute path,
even when the file is actually at that absolute location.
- The locators are used in the order in which they appear in the GUI,
and the Absolute one is first, so your problem doesn't make sense to me.
Thus, if you could help us reproduce it here, we can take a look and see
if there's a bug abound.
- It seems to me the debugger should be able to figure out the
difference between /src/projectRoot/a/main.cpp and
/src/projectRoot/b/main.cpp regardless of whether it is using relative or
absolute paths to lookup files first. Are you implying that the debugger
can only correctly find /src/projectRoot/b/main.cpp when it uses the
Absolute File Path locator?
- The AbsolutePathContainer is responsible for meeting the expectation
you just described, and note that it has highest priority among other
containers in the launch configuration. Again, why it's not working for
you is a bit of a mystery and we'll need to have a reproducible case to
figure out what's going on. Much easier, though, might be fore you to
troubleshoot the problem since you have the complex reproducible case.
You could then report back what you find. The key breakpoint for
troubleshooting this will be in
AbstractSourceLookupDirector.getSourceElement(Object). A source lookup
director is a composite entity which houses one or more containers to
be used in a search. A debug session uses a source director which will be
composed of the containers you see in the launch configuration. The
method I said to put a breakpoint in is the starting point for the
search.
- John
- _______________________________________________
- 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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev