Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Debug source lookup question

Thanks for the reply Mikhail.

> As we use only file names we need a mechanism to filter breakpoints that
> don't "belong" to the session. Note that CDT also support breakpoints
> set on external files. External files have no associated Eclipse
> resources and therefore can not be filtered according their project
> affiliation.

I get that we need to filter breakpoints by
resource-in-the-project-being-debugged.  My point was that this
feature currently doens't work and I believe there's good reason not
to be using the source locators to work out if a breakpoint should be

Eclipse IMarkers are associated with the IResources.  In your example
of an external source file, the breakpoint is set on the IProject (or
for external translation units without context they're set on the
WorkspaceRoot).  Now on launch we can perform a quick check to see if
the breakpoint marker is in the project being launched (see:
CBreakpointManager.isTargetBreakpoint()).  However if this check
fails, i.e. the marker is the workspaceroot, or set on a different
project, we fall back to using the source locators.

Most (if not all?) breakpoints set in CDT will have a marker attribute
ICBreakpoint.SOURCE_HANDLE equal to the source location.  Given that
AbsolutePathSourceContainer is used by the default c source lookup
participant, all breakpoints will automatically be resolved and set
during the launch.

> I am convinced the source lookup and the breakpoint setting mechanism in
> CDT should work "in sync". The right approach is to generate the content
> of the source lookup from the debug information stored in GDB and then
> allow users to map it to the file system. In this case we can translate
> absolute paths to the paths known to GDB.
> As for -environment-directory command, Volodya is right, CDT shouldn't
> use it.

I think that source lookup and breakpoint setting shouldn't be "in
sync" because of the above 'bug'.

The job of the source locator is to show you 'correct' source when CDT
is notified that the debugger has stopped at a particular location.
We don't care if the debugger stops in a file which maps to an
IResource in the debuggee project, a different project, or anywhere
else in the filesystem -- we still want to see some source (+/-
allowing the user to change the source lookup order they see by
In my view this is in contrast to the breakpoints mechanism which
should be attempting to filter breakpoints based on the launch
configuration context and the context of the breakpoint markers.



Back to the top