RE: [cdt-dev] Debug source lookup question

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

Sorry James, my example is not correct. The correct paths are
"/project/foo/../main.c" and "/project/main.c". The point is that both
represent the same file, but from the GDB's point of view there are
different.

> A better solution might be to look in the binary and check whether
there are any source file collisions before attempting to set
breakpoints.

That's what I am proposing, but instead of parsing the binary, we let
GDB to do the work and retrieve the list of source files and their paths
from GDB. In this case we can use absolute paths to set breakpoints. If
we need to set a breakpoint at "/project/main.c" the source lookup will
translate the path to "/project/foo/../main.c" and GDB will understand
it.
With absolute paths we won't have file collisions.

Mikhail

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of James Blackburn
Sent: Thursday, November 20, 2008 1:07 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Debug source lookup question

Hi Mikhail,

Not meaning to labour the point, but I think we have two separate issues
here.

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

I don't think there is a problem with it.  If execution stops at some
external absolute file path -- for example the user steps into a library
function (where the library has debug symbols) they should see the
source.  It would be overkill to force the user to add all external
source locations to the launch config "Source" tab.  For this
AbsolutePathSourceContainer does what it says on the tin.

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

I see there is a problem here, but it's not one the source locator
solves:
  - If both main.c's were in different projects, marker comparison would
spot this.
  - If they are in the same project, and not both built into the same
executable, your default Project Path Container would also fail --
there's a collision here and both exist in the source container.
  - If both main.c's are in the same project and built into the same
executable then you're scuppered if you don't select "Use full file path
to set breakpoints" as the breakpoints aren't disambiguated before being
set (cdt just uses main.c:xx as discussed previously).

A better solution might be to look in the binary and check whether there
are any source file collisions before attempting to set breakpoints.

>From my point of view, if you make the source locators too specific
(so breakpoints are filtered) then when the target stops you risk not
finding the source.  If you make it too general -- allowing it to
resolve all source on a best effort basis -- then all breakpoints are
set on launch.

Even though both features are based on sets of source files: the set of
files with breakpoints that will be set on launch,  is contained within
the set of source file locations we can resolve in the IDE, and not vice
versa.  (Obviously the sets are equivalent if we know exactly what files
are built into an executable, but this isn't what the source locator
provides.)

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.