|RE: [cdt-dev] Debug source lookup question
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.
Back to the top