Re: [cdt-dev] Debugger Source File Lookup

[Tim Black <timblaktu@xxxxxxxxx>]

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