RE: [cdt-dev] Debug source lookup question

["Mikhail Khodjaiants" <Mikhail.Khodjaiants@xxxxxxx>]

James,

I can't comment on the latest changes - haven't worked on or used
seriously a CDT/GDB based debugger for more than a year. If there is a
problem with AbsolutePathSourceContainer it should be fixed.
But I still think the synchronization with the source lookup is
required. If executable is compiled with "/foo/../main.c" setting a
breakpoint at "/foo/main.c" wouldn't work. And the source lookup is the
place where we can resolve this type of issues.

Mikhail
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of James Blackburn
Sent: Thursday, November 20, 2008 11:56 AM
To: CDT General developers list.
Subject: 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 enabled.

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 default).
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.

Cheers,

James
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

-- 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.