Community
Participate
Working Groups
The insert breakpoint action starts in MIBreakPointsManager.installBreakpoint() and trickles down to the MIBreakInsert command. Inside MIBreakInsert.java, the path parameter is set using: setParameters(new String[] { line }); The line variable contains a path with single backslashes. When the command is constructed, MICommand.constructCommand() is used, which in turn calls MICommand.parametersToString(). Inside MICommand.parametersToString() and MICommand.optionsToString(), backslashes are substituted with double backslashes: MICommand.parametersToString(): StringBuffer sb = new StringBuffer(); for (int i = 0; i < parameters.length; i++) { // We need to escape the double quotes and the backslash. sb.setLength(0); String param = parameters[i]; for (int j = 0; j < param.length(); j++) { char c = param.charAt(j); if (c == '"' || c == '\\') { sb.append('\\'); } sb.append(c); } This does not always work with all CodeSourcery MI commands, in this case the -break-insert command expects single backslashes. Solutions suggestions: Solution 1: If double backslashes is a standard, then CodeSourcery gdb should be fixed. Solution 2: Add MICommand.isSubstituteBackslash() which per default returns true. Introduce special CodeSourcery MI commands which inherits from the standard commands and overrides the method to return false where applicable. Solution 3: Remove the substitution thing from MICommand and put the responsibility on each command.
I suspect that these changes are not specific to CodeSourcery GDB. More likely, these commands are also broken in standard GDB, we just don't see it when debugging on Linux because Unix paths use forward slashes only. As long as these bugs exist in the latest version of GDB, I think it makes sense to add the workarounds into the standard commands until GDB is fixed. For those commands, it should be possible to override the parametersToString() command. After GDB fixes these commands, the workarounds will be removed.
Created attachment 90739 [details] Proposed implementation There are many patches in one file
Here is the console output from gdb with the patches: 395,551 1-interpreter-exec console echo 395,566 1^done 395,597 2-environment-directory C:\dev\cpp-workspace\GDB-test 395,613 2^done,source-path="C:\dev\cpp-workspace\GDB-test;$cdir;$cwd" Setting symbols file OK 395,613 3-gdb-set sysroot C:\Program\CodeSourcery\SourceryG++\arm-none-linux-gnueabi\libc 395,613 3^done Setting sysroot OK 395,613 4-target-select remote 192.168.0.10:12345 396,285 4^connected,thread-id="0",frame={addr="0x400007c0",func="_start",args=[],from="C:\Program\CodeSourcery\SourceryG++\arm-none-linux-gnueabi\libc/lib/ld-linux.so.3"} Connected to: null 396,410 5-break-insert C:\dev\cpp-workspace\GDB-test\Threads.cpp:24 396,426 5^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00008a84",func="printMsg(void*)",file="Threads.cpp",fullname="C:\dev\cpp-workspace\GDB-test/Threads.cpp",line="24",times="0"} 396,441 6-exec-run 396,441 6^running 396,457 &"Don't know how to run. Try "help target".\n"
Hi Tobias, The changes look fine to me. I just have a couple of procedural requests. 1) Please generate a single patch and use the Workspace as the patch root. 2) Please add a copyright notice to new files you've added, see http://www.eclipse.org/legal/copyrightandlicensenotice.php Thanks Pawel
Created attachment 90828 [details] Single patch for all changes (+committed, +logged) These patches also includes copyright notice.
I committed the patch. Francois could you please review as well and mark bug verified.
Hi Tobias, Is this patch complete or is it part of something larger? Here's what I get when I run in Windows with GDB 6.7.50.20071127 from MinGW: ======================= Configuration location: file:/C:/Eclipse/workspaces/DSF/.metadata/.plugins/org.eclipse.pde.core/DSF/ Configuration file: file:/C:/Eclipse/workspaces/DSF/.metadata/.plugins/org.eclipse.pde.core/DSF/config.ini loaded Install location: file:/C:/Eclipse/Ganymede/ Framework located: file:/C:/Eclipse/Ganymede/plugins/org.eclipse.osgi_3.4.0.v20080205.jar Framework classpath: file:/C:/Eclipse/Ganymede/plugins/org.eclipse.osgi_3.4.0.v20080205.jar Splash location: C:\Eclipse\Ganymede\plugins\org.eclipse.platform_3.3.100.I20080204-0800\splash.bmp Debug options: file:/C:/Eclipse/workspaces/DSF/.metadata/.plugins/org.eclipse.pde.core/DSF/.options loaded Time to load bundles: 16 Starting application: 1312 Application Started: 12890 990,049 1-interpreter-exec console echo 990,065 1^done 990,330 2-thread-list-ids 990,330 3-break-insert C:\Eclipse\workspaces\suntime-DSF\Templates\src\Templates.cpp:173 990,330 2^done,thread-ids={},number-of-threads="0" 990,346 &"No source file named C:\Eclipse\workspaces\suntime-DSF\Templates\src\Templates.cpp.\n" 990,346 &"No source file named C:\Eclipse\workspaces\suntime-DSF\Templates\src\Templates.cpp.\n" 3^error,msg="No source file named C:\Eclipse\workspaces\suntime-DSF\Templates\src\Templates.cpp." ... [lines deleted] ======================= And, of course, the breakpoint is not set. To me this points to a source lookup problem (at least in my case!). From the bug thread, I see that you are using the CodeSourcery debugger (presumably equivalent to MinGW's) and that you connect to a remote host (Linux?) running your application. My understanding is that the setting of sysroot is relevant for the libraries but not for source files (correct?). The environment directory command does in fact relate to the source files but, since we are providing an absolute path to the file, it is more or less needed. I'm curious as to how you made it work. Any other tweaks your patch depends on? My feeling is that this is a fix to a bigger problem and that a dependency should be added accordingly. Anyway, the patch replaces "\\" by "\" on the break-insert command and it won't break the Linux code until someone decides to create a Linux path with a "\" in its name (although possible, a bad idea in the first place). So, if it's OK with Pawel, it's OK with me. BR, /fc
(In reply to comment #7) Hi Francois, This patch needs a launcher which sets the source lookup path just like the CDT debug launcher does. The launcher is what Marc is working on right now. I have added some launch steps in my LaunchSequence.java in order for getting my patch to work, the patches which I have sent to dsdp-dd-dev. Maybe a new bug report should be filed about using "-environment-directory" during launch?
Closing out 1.0 bugs.
