Community
Participate
Working Groups
Some build systems set DW_AT_comp_dir in DWARF to "/proc/self/cwd", which simply means the current working directory. This value propagates to fullname returned by gdb, for example: 412,903 21-break-insert --thread-group i1 -f mydir/myfile.cc:82 412,986 21^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040ca8f",func="MyTest_Test::TestBody()",file="mydir/myfile.cc",fullname="/proc/self/cwd/mydir/myfile.cc",line="82",thread-groups=["i1"],times="0",original-location="mydir/myfile.cc:82"} If the debugger runs in a directory different from the compilation directory, the fullname path becomes invalid, and CDT is not able to find the source file when the breakpoint is hit.
http://sourceware.org/ml/gdb-patches/2012-12/msg00811.html describes the GDB change called "Print MI fullname even for non-existing files". It looks like this change is to blame for the source lookup breakage described in comment #0. On 20 Dec 2012 Marc Khouzam wrote about this change: "So I find the patch in fact an improvement even for Eclipse." It seems that this conclusion should be reconsidered. One possible solution is to validate fullname path immediately upon receiving it from GDB and discard it if the file it points to doesn't exist.
A proposed fix is in Gerrit at https://git.eclipse.org/r/#/c/12964/.
(In reply to comment #2) > A proposed fix is in Gerrit at https://git.eclipse.org/r/#/c/12964/. Sergey, Would your patch work if the executable is built somewhere else? With the current code we can still debug it using the path mapping mechanism.
(In reply to comment #3) > Would your patch work if the executable is built somewhere else? With the > current code we can still debug it using the path mapping mechanism. The patch does work if the source lookup is configured properly since the files are found by their relative paths. Perhaps it would be better to apply path mapping and check for file existence at the same time. Could you please point me to the path mapping code. Thanks.
(In reply to comment #4) > (In reply to comment #3) > > Would your patch work if the executable is built somewhere else? With the > > current code we can still debug it using the path mapping mechanism. > > The patch does work if the source lookup is configured properly since the > files are found by their relative paths. > > Perhaps it would be better to apply path mapping and check for file > existence at the same time. Could you please point me to the path mapping > code. Thanks. Not sure I understand what you mean. There is no way to specify a file that doesn't exist as local file using the path mapping mechanism. The UI doesn't allow it. The source containers are: org.eclipse.cdt.debug.core.sourcelookup.MappingSourceContainer org.eclipse.cdt.debug.internal.core.sourcelookup.MapEntrySourceContainer
(In reply to comment #5) > Not sure I understand what you mean. There is no way to specify a file that > doesn't exist as local file using the path mapping mechanism. The UI doesn't > allow it. > The source containers are: > org.eclipse.cdt.debug.core.sourcelookup.MappingSourceContainer > org.eclipse.cdt.debug.internal.core.sourcelookup.MapEntrySourceContainer I meant that ideally the check for existence should be done after an attempt to map the file. If that attempt is unsuccessful and the file doesn't exist, the absolute path should be ignored.
(In reply to comment #6) > (In reply to comment #5) > > Not sure I understand what you mean. There is no way to specify a file that > > doesn't exist as local file using the path mapping mechanism. The UI doesn't > > allow it. > > The source containers are: > > org.eclipse.cdt.debug.core.sourcelookup.MappingSourceContainer > > org.eclipse.cdt.debug.internal.core.sourcelookup.MapEntrySourceContainer > > I meant that ideally the check for existence should be done after an attempt > to map the file. If that attempt is unsuccessful and the file doesn't exist, > the absolute path should be ignored. What if we just add a special global path mapping for your case? With proposed changes the source lookup would often find a wrong file.
(In reply to comment #7) > What if we just add a special global path mapping for your case? With > proposed changes the source lookup would often find a wrong file. A global path mapping would not work since different sources are compiled in different compilation directories. These compilation directories are all represented by /proc/self/cwd in fullname. Relative paths do work because they are resolved against source lookup that is aware of all compilation directories.
(In reply to comment #8) > (In reply to comment #7) > > What if we just add a special global path mapping for your case? With > > proposed changes the source lookup would often find a wrong file. > > A global path mapping would not work since different sources are compiled in > different compilation directories. These compilation directories are all > represented by /proc/self/cwd in fullname. Relative paths do work because > they are resolved against source lookup that is aware of all compilation > directories. Yes, I realized it after reading the description once again. I see two options: 1. Using the source lookup twice, first time with the full path and then with the relative path. 2. Strip '/proc/self/cwd' before passing the file name to the source lookup. What do you think?
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > What if we just add a special global path mapping for your case? With > > > proposed changes the source lookup would often find a wrong file. > > > > A global path mapping would not work since different sources are compiled in > > different compilation directories. These compilation directories are all > > represented by /proc/self/cwd in fullname. Relative paths do work because > > they are resolved against source lookup that is aware of all compilation > > directories. > > Yes, I realized it after reading the description once again. > I see two options: > 1. Using the source lookup twice, first time with the full path and then > with the relative path. > 2. Strip '/proc/self/cwd' before passing the file name to the source lookup. > What do you think? Option 1 looks like a more general and robust solution. I'm not sure how to fit it into existing code structure though.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > (In reply to comment #7) > > > > What if we just add a special global path mapping for your case? With > > > > proposed changes the source lookup would often find a wrong file. > > > > > > A global path mapping would not work since different sources are compiled in > > > different compilation directories. These compilation directories are all > > > represented by /proc/self/cwd in fullname. Relative paths do work because > > > they are resolved against source lookup that is aware of all compilation > > > directories. > > > > Yes, I realized it after reading the description once again. > > I see two options: > > 1. Using the source lookup twice, first time with the full path and then > > with the relative path. > > 2. Strip '/proc/self/cwd' before passing the file name to the source lookup. > > What do you think? > > Option 1 looks like a more general and robust solution. I'm not sure how to > fit it into existing code structure though. I think using a new service that extends CSourceLookup for affected GDB versions would work. We just need to override ISourceLookup.getSource(). BTW, can you set a breakpoint with those full paths?
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > (In reply to comment #8) > > > > (In reply to comment #7) > > > > > What if we just add a special global path mapping for your case? With > > > > > proposed changes the source lookup would often find a wrong file. > > > > > > > > A global path mapping would not work since different sources are compiled in > > > > different compilation directories. These compilation directories are all > > > > represented by /proc/self/cwd in fullname. Relative paths do work because > > > > they are resolved against source lookup that is aware of all compilation > > > > directories. > > > > > > Yes, I realized it after reading the description once again. > > > I see two options: > > > 1. Using the source lookup twice, first time with the full path and then > > > with the relative path. > > > 2. Strip '/proc/self/cwd' before passing the file name to the source lookup. > > > What do you think? > > > > Option 1 looks like a more general and robust solution. I'm not sure how to > > fit it into existing code structure though. > > I think using a new service that extends CSourceLookup for affected GDB > versions would work. We just need to override ISourceLookup.getSource(). Sorry, I am too tired. Overriding ISourceLookup.getSource() doesn't work. We need two paths (absolute and relative) but it only accepts one. I think the second option is easier to implement. > BTW, can you set a breakpoint with those full paths?
I've implemented a local solution to this problem, so we can leave the current behavior in place as long as nobody else is suffering from it.
I believe this bug is fixed by Bug 472765. With the changes in Bug 472765 the path mapping maps /proc/self/cwd/mydir to /the/real/path/to/mydir and does a "set substitute-path /proc/self/cwd/mydir /the/real/path/to/mydir", after the substitution is issued to GDB, further breakpoints can be inserted on /the/real/path/to/mydir/myfile.cc and GDB will report fullname as /the/real/path/to/mydir/myfile.cc too. However, I don't have access to a GCC that behaves this way so I cannot test.
(In reply to Jonah Graham from comment #14) > I believe this bug is fixed by Bug 472765. With the changes in Bug 472765 > the path mapping maps /proc/self/cwd/mydir to /the/real/path/to/mydir and > does a "set substitute-path /proc/self/cwd/mydir /the/real/path/to/mydir", > after the substitution is issued to GDB, further breakpoints can be inserted > on /the/real/path/to/mydir/myfile.cc and GDB will report fullname as > /the/real/path/to/mydir/myfile.cc too. > > However, I don't have access to a GCC that behaves this way so I cannot test. While this bug is significantly improved by Bug 472765's fixes, there are still some cases that CDT does not handle because GDB does not handle them. Namely, in the case that /proc/self/cwd actually refers to two different locations GDB cannot resolve it. Here is an example of how someone sets DW_AT_comp_dir in DWARF to "/proc/self/cwd". It is about llvm but the principle is the same. http://lists.llvm.org/pipermail/cfe-dev/2011-October/018068.html That said, the long term fix needs to be on the GDB side, i.e. there needs to be a way to configure GDB to work in this case with no CDT involved. If there is a delay in GDB providing a fix, then CDT can have a workaround until the proper fix is available.
Created attachment 260886 [details] example script demoing PWD issue This script shows how to create an executable with DW_AT_comp_dir that become unresolvable by GDB.
