RE: [cdt-dev] Debug source lookup question

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

James,

Currently the CDT source lookup mechanism doesn't retrieve the source
information from GDB. Which means that the CDT debugger is unable in
many cases to associate the file paths known to CDT to the paths stored
in the debug information in GDB. As a result we don't use absolute paths
to set breakpoints. (There is a new option added by Elena that allows to
use absolute paths. This option only works if the debug information
contains only absolute paths but will cause more problems in many other
cases.)
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 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.

Regards,
Mikhail
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of James Blackburn
Sent: Wednesday, November 19, 2008 7:22 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Debug source lookup question

> I know about both, and will likely force them for new projects. The 
> question I'm trying to establish -- primarily for our product, but 
> also in general -- is whether CDT should *ever* sent
-environment-directory command.
>
> One case where -environment-directory might still be needed is when 
> user adds a source directory via CDT, and then uses commands like 
> "list" in GDB console -- which probably check the same paths. I don't
know how common this use case is.

That's the only case I can think of as well.

For what it's worth, our target's launch only uses the absolute path
source lookup as well.  The reason I did this was the very long launch
startup-time we were seeing when discovering all the project paths to
pass to GDB (we run our Eclipses over NFS filesystems...).  See bug:
https://bugs.eclipse.org/225708

There are a number of peculiarities to do with launch and source paths.
Previously, for example, the debugger would not attempt to set
breakpoints if the source location of the breakpoint couldn't be
resolved via the source lookup mechanism.  Elena committed a patch to
fix this (breakpoints are now set if the marker's IResource is in the
project) -- bug: https://bugs.eclipse.org/247851 .  Source lookup is
still used as a backup (which, as the absolute path container always
resolves the file, is probably wrong...).  I'm not sure either of use
figure out why the breakpoints are resolved via the source lookup
mechanism in the first place.  Mikhail perhaps you can shed some light
on this?

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.