Community
Participate
Working Groups
Build ID: I20070323-1616 Steps To Reproduce: Issue a 'run to line' command from CDT when using a windows gdb that uses native windows paths e.g. not cygpath. More information: Full windows paths contain colons after the drive letter - gdb cannot parse this in an exec-until command at is requires a colon to specify the source line number. Run to line needs to use the same mechanism as breakpoints i.e. relative paths, to avoid this problem.
I found this problem when running Eclipse Helios CDT on Windows with Wascana installed. As Mike suggests, it could be fixed by making run to line sets breakpoints the same way as breakpoints mechanism. Is there any other problem that makes this issue remain open? Regards, Patxi.
As a note, DSF-GDB uses a temporary breakpoint for "run-to-line" instead of -exec-until, which may solve your problem.
(In reply to comment #2) > As a note, DSF-GDB uses a temporary breakpoint for "run-to-line" instead of > -exec-until, which may solve your problem. But I think the problem is the path, which I suppose still needs to be specified when using -exec-until (please, tell me if I'm wrong). I've made some investigation on this problem. My C project structure: HelloC +-Debug +-HelloC.exe +-src +-HelloC.c If I start gdb from src folder, and I try to set a breakpoint using absolute path it fails. I've tried in several ways (like single and double backslashes), and none work. However, if I just specify the name of the source file (HelloC.c), it works perfectly. I'm not an expert and have no idea why absolute paths don't work on Windows (I'm using MinGW). Having a look at the code, I've seen that the method that sets the temporary breakpoint is RunToLine.runToLine(). If I change the method, so that only the last segment of the path is passed into the IRunControl2.runToLine call, it works perfectly. Obviously, this approach doesn't work if the file is within a folder (which sounds strange, but my days as C develeoper passed by some years ago, so I can be wrong) or there are several source folders. Also, I don't know the impact of this change in other OS: ##code## public void runToLine(final String fileName, final int lineNumber, final boolean skipBreakpoints) throws DebugException { ... IPath path = Path.fromPortableString(fileName); String lastSegment = path.lastSegment(); runControl.runToLine(fContext, lastSegment, lineNumber, skipBreakpoints, rm); ... } ##code## Ideally, I would have made the path relative (Path.makeRelative()) to the src folder. But I don't know if that information could be retrieved from that method in some way. Another approach would be to modify MIBreakInsert.PathAdjustable, which seems to "normalize" the path for gdb. I think it makes more sense for me. Any suggestions?
Created attachment 179524 [details] Patch for CDT V201006141710 This is a patch for tag 201006141710
I'll take a look at this patch.
This patch fixes the problem at an inappropriate location. The fix should be somewhere in the MI plugin, not the dsf action code. Reducing the path down to a simple filename is an ugly hack, but a seemingly unavoidable one (see bug 232415). The obvious pitfall with the hack is that it drops support for executables with same-named files (e.g., two foo.cpp files in different directories). The hack should be as closely tied to the problem environment as possible. In this case, that environment is GDB, specifically MinGW's. Unfortunately, the MinGW distinction is not one I think we currently are able to make in dsf-gdb, but at least the fix should be pushed down into the MI plugin. I'll relocate the fix.
Created attachment 179662 [details] reworked fix
Committed to HEAD. Marc please review. If you think this is safe enough, I'll commit it to the 7.0.x branch, too.
(In reply to comment #8) > Committed to HEAD. Marc please review. If you think this is safe enough, I'll > commit it to the 7.0.x branch, too. Nice. I'll try it on my Windows machine tonight. Why do we need path = path.replace('\\', '/'); which we didn't before? I think you need the same fix in GDBRunControl_7_0_NS#runToLine.
Just a note that this bug is assigned to CDI... Should we move it to the DSF-GDB component and open a new one for CDI?
(In reply to comment #9) > (In reply to comment #8) > > Committed to HEAD. Marc please review. If you think this is safe enough, I'll > > commit it to the 7.0.x branch, too. > > Nice. I'll try it on my Windows machine tonight. > > Why do we need > path = path.replace('\\', '/'); > which we didn't before? In some cases, the input path has forward slashes. In some, it has backslashes. Depends on the calling feature (e.g., breakpoint vs run-to-line). > I think you need the same fix in GDBRunControl_7_0_NS#runToLine. OK. I'll add it there, too.
(In reply to comment #10) > Just a note that this bug is assigned to CDI... Should we move it to the > DSF-GDB component and open a new one for CDI? Yes. We should move it to dsf-gdb. As for CDI...I don't know. I guess we'd have to try reproducing the problem with a CDI session.
(In reply to comment #11) > (In reply to comment #9) > > (In reply to comment #8) > > > Committed to HEAD. Marc please review. If you think this is safe enough, I'll > > > commit it to the 7.0.x branch, too. > > > > Nice. I'll try it on my Windows machine tonight. Looks good to me. Does making MIBreakpointsManager.adjustDebuggerPath visible not require a @since tag? The API tooling did not ask for one. I guess because it is static? +1 for the 7_0 branch, once GDBRunControl_7_0_NS has the same fix. Thanks
(In reply to comment #12) > (In reply to comment #10) > > Just a note that this bug is assigned to CDI... Should we move it to the > > DSF-GDB component and open a new one for CDI? > > Yes. We should move it to dsf-gdb. As for CDI...I don't know. I guess we'd have > to try reproducing the problem with a CDI session. I tried to reproduce it with CDI with GDB 6.8 and 7.0 and I didn't see the problem. I'm thinking that Francisco, in comment #1, was using DSF-GDB since it is the default for Helios. So, I figured we can move this bug to cdt-debug and use it to mark both DSF-GDB and CDI fixed for this issue.
(In reply to comment #13) > Does making MIBreakpointsManager.adjustDebuggerPath visible not require a > @since tag? The API tooling did not ask for one. I guess because it is > static? My fix changed the method to package (default) visibility, which is still non-public.
(In reply to comment #13) > +1 for the 7_0 branch, once GDBRunControl_7_0_NS has the same fix. The fix is now in 7.0.x and in GDBRunControl_7_0_NS
(In reply to comment #16) > (In reply to comment #13) > > +1 for the 7_0 branch, once GDBRunControl_7_0_NS has the same fix. > > The fix is now in 7.0.x and in GDBRunControl_7_0_NS Should we make MIBreakpointsManager.adjustDebuggerPath public in HEAD (only) to avoid duplication of code in GDBRunControl_7_0_NS ? I can do it if you agree.
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #13) > > > +1 for the 7_0 branch, once GDBRunControl_7_0_NS has the same fix. > > > > The fix is now in 7.0.x and in GDBRunControl_7_0_NS > > Should we make MIBreakpointsManager.adjustDebuggerPath public in HEAD (only) to > avoid duplication of code in GDBRunControl_7_0_NS ? > > I can do it if you agree. I don't think we should. It's a method that exists only to support a hack. I don't think we should make it API. It's a small enough method that duplicating it is not a big deal, IMO.
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > > (In reply to comment #13) > > > > +1 for the 7_0 branch, once GDBRunControl_7_0_NS has the same fix. > > > > > > The fix is now in 7.0.x and in GDBRunControl_7_0_NS > > > > Should we make MIBreakpointsManager.adjustDebuggerPath public in HEAD (only) to > > avoid duplication of code in GDBRunControl_7_0_NS ? > > > > I can do it if you agree. > > I don't think we should. It's a method that exists only to support a hack. I > don't think we should make it API. It's a small enough method that duplicating > it is not a big deal, IMO. Valid point. Ok. thanks for the fix.
(In reply to comment #19) > Valid point. Ok. That said, we could move the method to some internal package and make it public. It's up to you.
(In reply to comment #20) > (In reply to comment #19) > > Valid point. Ok. > > That said, we could move the method to some internal package and make it > public. It's up to you. No worth the effort I think. Maybe when and if we have to use it again somewhere else.
