[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Debugger Source File Lookup
|
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)
AndrewOn 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?
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
