Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
cygdriveprefix can interfere with debugging
crc1021:
I found this referenced earlier here:
http://forums.codeblocks.org/index.php/topic,6286.5/wap2.html
I have same issue. I set cygdriveprefix to '/' to keep it short and also to match msys paths. The gdb driver looks for an occurrence of cygdriveprefix in the path to guess that it is a cygwin path (in gdb_driver.cpp, GDB_driver::CorrectCygwinPath). That corrupts a windows path in my case (and possibly others).
Since gdb outputs the windows path with DRIVE:, I think the fix would be to look for cygdriveprefix only at the start of the path (after skipping the 2 gdb markers 0x1A).
crc1021:
I posted a small patch that should fix this. Patch ID 002273.
thomas:
Can you provide detailled information for the problem please (I'm too stupid to grasp it) ?
The reason why I am asking is that I am working on an implementation of path handling in Code::Blocks which shall replace all the nasty tampering (manually replacing / with \, concatenating strings, and the like) that we currently do.
Now, if there are any special quirks that I'm not aware of, it would be good to know, since I'd want it to "just work" :)
If I understand correctly, a pathname in Cygwin looks like /cygdrive/c/foo/bar - in MSys it would be /c/foo/bar. That is pretty much a "normal" Unix pathname, which should not pose a problem.
I guess as much as setting cygdriveprefix to / means as much as eleminating the /cygdrive part.
So what does the path you have look like, and what should it look like? Also, is cygdriveprefix an environment variable, or a compile-time constant, or what is it?
crc1021:
Yes, the cygwin path looks like /cygdrive/c/foo/bar, but the "/cygdrive" part is configurable and is stored in the registry. I set the configurable part (cygdriveprefix) to be "/" so the paths are not obnoxious and so they match msys.
If a codeblocks user is using cygwin gdb rather than mingw gdb, the paths coming back from gdb will be in cygwin notation. So, codeblocks (specifically the gdb_driver) tries to recognize a cygwin path and convert it to win32 path so codeblocks can find the file mentioned by gdb when debugging (like when hitting a breakpoint).
The problem lies in that is gdb_driver decides the path is a cygwin path if cygdriveprefix is found anywhere in the path string. Because the mingw gdb output paths in the form: "C:/foo/bar", if the cygdrive prefix is changed to "/" it will be found in all paths coming back from gdb. Also, if the unaltered cygdriveprefix happens to match any place in the path (such as "C:/foo/bar/cygdrive/code"), gdb_driver will also call it a cygwin path. When a cygwin path is "found", gdb_driver removes the cygdriveprefix and puts in the "C:". When a path incorrectly matches, a valid path gets corrupted.
By just matching cygdriveprefix against the start of the path returned by gdb, the problem should be resolved.
MortenMacFly:
--- Quote from: crc1021 on December 06, 2007, 09:30:25 pm ---Yes, the cygwin path looks like /cygdrive/c/foo/bar,
[...]
By just matching cygdriveprefix against the start of the path returned by gdb, the problem should be resolved.
--- End quote ---
Let me try - I am using Cygwin but without Cygdrive modifications... Never debugged a Cygwin app using C::B either... let me try...
Navigation
[0] Message Index
[#] Next page
Go to full version