Bugzilla – Full Text Bug Listing
| Summary: | CDT debugger shows the wrong source file if filenames are the same | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Scott Bronson <brons_eclipsebugzilla> | ||||
| Component: | cdt-debug-cdi-gdb | Assignee: | John Cortell <john.cortell> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | aegges, elaskavaia.cdt, john.cortell, marc.khouzam, nobody, panagiotis, shaybh, victor.zverovich | ||||
| Version: | 4.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
I'm having the same problem here when trying to debug ffmpeg. The av_seek_frame() function is located in a file called libavformat/utils.c on line 1297, but the Eclipse debugger opens libavcodec/utils.c on line 1297 instead, where a different function is located. I do think the correct code is being executed, but Eclipse CDT shows the wrong files and lines. You have to use absolute file paths for the breakpoints. This can be configured in the Debug Launch Configuration (Debugger tab). (In reply to comment #2) > You have to use absolute file paths for the breakpoints. This can be configured > in the Debug Launch Configuration (Debugger tab). Note that this pitfall is not present in DSF-GDB, as absolute paths are always used. The CDI-GDB plugin's use of simple names, particularly by default, is a misguided attempt to support executables "built on another machine" without requiring them to set up path mappings. (In reply to comment #3) > Note that this pitfall is not present in DSF-GDB, as absolute paths are always > used. The CDI-GDB plugin's use of simple names, particularly by default, is a > misguided attempt to support executables "built on another machine" without > requiring them to set up path mappings. It was done because we couldn't use absolute paths with some earlier versions of gdb. If "/foo/main.c" is stored in the executable as "/Debug/../foo/main.c" gdb (or used to) treats these two paths as diffierent. It seems that this problem is solved but I need to confirm it. (In reply to comment #3) > Note that this pitfall is not present in DSF-GDB, as absolute paths are always > used. The CDI-GDB plugin's use of simple names, particularly by default, is a > misguided attempt to support executables "built on another machine" without > requiring them to set up path mappings. Wouldn't it be better then to activate the option "Use full file path to set breakpoints" per default for CDI-GDB? Or are there any drawbacks? I guess debugging executables that were built on another machine is not the default case for most users. And in this case you can setup path mapping. I think this would be much more logical and would meet the users expectations. (In reply to comment #4) > (In reply to comment #3) > > Note that this pitfall is not present in DSF-GDB, as absolute paths are always > > used. The CDI-GDB plugin's use of simple names, particularly by default, is a > > misguided attempt to support executables "built on another machine" without > > requiring them to set up path mappings. > > It was done because we couldn't use absolute paths with some earlier versions > of gdb. If "/foo/main.c" is stored in the executable as "/Debug/../foo/main.c" > gdb (or used to) treats these two paths as diffierent. > It seems that this problem is solved but I need to confirm it. I guess the motivation was misrepresented to me. I recently was told that behavior was there to handle the scenario I described. (In reply to comment #5) > (In reply to comment #3) > > Note that this pitfall is not present in DSF-GDB, as absolute paths are always > > used. The CDI-GDB plugin's use of simple names, particularly by default, is a > > misguided attempt to support executables "built on another machine" without > > requiring them to set up path mappings. > Wouldn't it be better then to activate the option "Use full file path to set > breakpoints" per default for CDI-GDB? Or are there any drawbacks? I guess > debugging executables that were built on another machine is not the default > case for most users. And in this case you can setup path mapping. I think this > would be much more logical and would meet the users expectations. I'm all for it. If other committers are also, I'll be happy to change it. +1 if the problem is fixed in GDB. (In reply to comment #8) > +1 if the problem is fixed in GDB. Even if gdb does in some cases put relative paths in the symbolics, the new RelativePath container will find the file (In reply to comment #9) > Even if gdb does in some cases put relative paths in the symbolics, the new > RelativePath container will find the file The problem is not to find a file in CDT but to present the file name to gdb that it understands it. If the path in executable is presented as "/Debug/../foo" and you want to set a breakpoint in "/foo/main.c" you need to convert "/foo/main.c" to "/Debug/../foo/main.c". I don't think RelativePath container can do that. (In reply to comment #10) > (In reply to comment #9) > > Even if gdb does in some cases put relative paths in the symbolics, the new > > RelativePath container will find the file > > The problem is not to find a file in CDT but to present the file name to gdb > that it understands it. If the path in executable is presented as > "/Debug/../foo" and you want to set a breakpoint in "/foo/main.c" you need to > convert "/foo/main.c" to "/Debug/../foo/main.c". I don't think RelativePath > container can do that. Good point. So, right, that new container won't help in this situation. So, I have to imagine this is fixed in gdb otherwise the DSF-GDB guys would have run into it and would be having to deal with it in perhaps a similar way. (In reply to comment #11) > Good point. So, right, that new container won't help in this situation. So, I > have to imagine this is fixed in gdb otherwise the DSF-GDB guys would have run > into it and would be having to deal with it in perhaps a similar way. Sorry, I can't help here as I have no recollection of seeing that issue. (In reply to comment #12) > Sorry, I can't help here as I have no recollection of seeing that issue. I've sent an email to clarify it. You need to compile your source in a certain way to reproduce it. We ran into it immediately because at the beginning the Managed Build was using relative paths. I believe they have switched to absolute paths. If I wasn't lazy I would find the bugzilla. (In reply to comment #13) > I've sent an email to clarify it. Here is the answer: If nothing tells GDB where the sources are, it still has trouble comparing them. If it does know where they are, I think it can canonicalize them to compare. (In reply to comment #14) > (In reply to comment #13) > > I've sent an email to clarify it. > > Here is the answer: > > If nothing tells GDB where the sources are, it still has trouble comparing > them. If it does know where they are, I think it can canonicalize them to > compare. Cool. I'll change the launch config to have 'use absolute paths' checked by default. Will do this hopefully by early next week. We can switch it to default for sure, but I don't know how path mapping can solve this. If binary compiled in another host and is has different paths, does CDT read paths from the binary and maps them BEFORE trying to set a breakpoint? (In reply to comment #16) > We can switch it to default for sure, but I don't know how path mapping can > solve this. If binary compiled in another host and is has different paths, > does CDT read paths from the binary and maps them BEFORE trying to set a > breakpoint? CDT maps the local source file to whatever you map it to and then sets a breakpoint on that path. That assuming you have a single path mapping? If you have more or you have different source lookups it won't work right? (In reply to comment #18) > That assuming you have a single path mapping? If you have more or you > have different source lookups it won't work right? Well, it uses the first match. So, if there's more than one, it may work or it may not work. That's why generally speaking it's preferable to have path mappings in launch configurations rather than in the global prefs. Created attachment 164573 [details]
Turns on the "use full path..." checkbox by default
When you create a new CDI-based launch configuration, the "use full path..." checkbox is now on by default.
Committed to HEAD I need to undo this change and restore the default of using simple names when setting breakpoints. Not sure how I missed it, but gdb 6.8 and even 7.0 aren't smart about canonicalizing path names after all. Check out the failing break-insert command using a full path 23-break-insert C:/eclipse_3.6M6/runtime-New_configuration/hello/src/main.c:16 23^error,msg="No source file named C:/eclipse_3.6M6/runtime-New_configuration/hello/src/main.c." ...yet, if I do 'info source' I see 24-interpreter-exec console "info source" ~"Current source file is ../src/main.c\n" Current source file is ../src/main.c ~"Compilation directory is C:\\eclipse_3.6M6\\runtime-New_configuration\\hello\\Debug\n" Compilation directory is C:\eclipse_3.6M6\runtime-New_configuration\hello\Debug ~"Located in C:/eclipse_3.6M6/runtime-New_configuration/hello/Debug/../src/main.c\n" Located in C:/eclipse_3.6M6/runtime-New_configuration/hello/Debug/../src/main.c So. by default, gcc uses relative paths in the symbolics, and gdb isn't smart enough to canonicalize the paths to support full paths in the breakpoint requests. Maybe it's supported in HEAD gdb, but certainly not in 7.0. What this means for this bug is that the user will have to know how to flip the switch in gcc to get it to generate absolute paths in the symbolics, and then know to turn on the "use full paths" in the launch configuration. A lot to remember and to know, unfortunately, but gdb is giving us no love. (In reply to comment #22) > I need to undo this change and restore the default of using simple names when > setting breakpoints. Not sure how I missed it, but gdb 6.8 and even 7.0 aren't > smart about canonicalizing path names after all. GDB 7.1 does canonicalization on Linux: viz@dione:~/workspace/eclipse/test/bin$ gdb ./a.out GNU gdb (GDB) 7.1-ubuntu ... Reading symbols from /home/viz/workspace/eclipse/test/bin/a.out...done. (gdb) break ../src/test.cpp:3 Breakpoint 1 at 0x8048427: file ../src/test.cpp, line 3. ------------------------------------------------------------ viz@dione:~/workspace/eclipse/test/bin$ gdb a.out GNU gdb (GDB) 7.1-ubuntu ... Reading symbols from /home/viz/workspace/eclipse/test/bin/a.out...done. (gdb) break /home/viz/workspace/eclipse/test/src/test.cpp:3 Breakpoint 1 at 0x8048427: file ../src/test.cpp, line 3. Does the version 7.1 work for you? If not then it is probably a Windows-specific bug and it makes sense to submit a bug report to GDB. |
Build ID: 3.3.0 (CDT M5) Steps To Reproduce: If you have two files in your project with identical names, the CDT debugger always uses the one that comes first alphabetically by depth! I have a project that looks like this: project/ main.c -- main routine for whole project project.exe -- executable for whole project module/ -- directory containing a module for the project main.c -- mutest's source file module.exe -- inner module's executable (unit tests) When I try to run module.exe under the debugger, the debugging perspective displays project/main.c, not project/module/main.c. The program counter is displayed and everything works as if module/main.c actually were visible. The only problem is that the wrong file is displayed. FWIW, all other debuggers I've tried (ddd, Nemiver, kgdb, etc) work fine in this scenario; this behavior appears unique to Eclipse. I think the problem is how CDT sets the source search directories (from the GDB log): $ directory /home/bronson/workspace/tmtest /home/bronson/workspace/tmtest/.settings /home/bronson/workspace/tmtest/examples etc... In other words, CDT just adds directories alphabetically, shallowest to deepest. That only works if you don't have any duplicate filenames in your project! WORKAROUND: If I start debugging project/module/module.exe and, type 'directory $cdir:$cwd' into the debugger console, and then step once, this fixes everything. The debugger perspective suddenly shows the correct source file and everything works as it should. EASY FIX: I'm pretty sure you can have CDT to continue setting the search paths as it does now, but then afterward simply re-add $cdir and $cwd by running another dir command. $ directory d1/a d1/a/1 d1/b etc. (current behavior) $ directory $cdir:$cwd (new command) HARDER FIX: A more difficult but potentially more correct fix would be to have CDT order its directories to be relevant to the cdir of the currently executing binary. That way, it would move /project/module and all of its subdirs to a higher priority than /project. I hope one of these fixes can make it into M6! More information: