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]

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.

Let me try - I am using Cygwin but without Cygdrive modifications... Never debugged a Cygwin app using C::B either... let me try...

[MortenMacFly]

Done. Please try SVN r4712... (Although it was not as easy as just looking for the prefix on the start... ;-)).

[crc1021]

I'll try it out on the next nightly build (I'm not setup to build it right now).  It is only harder if you still want the cygwin gdb paths to work. :wink:

[crc1021]

That change fixes the problem I described.  Thanks.

Another issue I see is that if code is compiled in the Cygwin of Msys environment and the compilation path is in a mounted path for that environment, the debug information will have paths that look like this "/home/user/prj" rather than "/cygdrive/c/home/user/prj".  This happens if "C:\home" is mounted as "/home" in either Cygwin or Msys.  Without the cygdrive prefix, the the function CorrectCygwinPath can not put in the "C:" notation.  It seems without a "C:", some other function believes the path is relative and tries to open a file that looks like this:
C:\home\user\prj\<esc><esc>\home\user\prj\file.cpp

[MortenMacFly]

Sorry for the delayed answer - you post slipped through my notification.

This happens if "C:\home" is mounted as "/home" in either Cygwin or Msys.

Why would you do that? And how? That would help me to reproduce.

But anyway - am I right that you would have no chance to get the root directory of home then? Because that info is simply missing at the point the debugger gets the info. If so than that's a bug you have to live with, I guess. But that would be OK - because if anybody mounts home in such a weired way (at least weired on Windows) than he is responsible himself.

With regards, Morten.

[thomas]

Why would you do that? And how? That would help me to reproduce.

Why: It is comfortable. I do that as well for a couple of locations, and MSys does it by default with MinGW's installation path, too.

How: fstab, just like under Unix.

[crc1021]

Under cygwin it is done with the mount command (mount c:\\home /home), under msys it is done with fstab entries (as mentioned already).  I do that to bring a common root to all systems.  The normal "root" for cygwin is "c:\cygwin" and for msys it is "c:\msys\1.0".  My work usually is in only a couple places like "c:\home" or "c:\prj" or something like that.  When I mount those into the root of cygwin or msys, the a path like "/prj/foo/code" and "/home/joe/.ssh" work in all environments.

Yes, if a path like "c:\Documents and Settings\joe\Local Settings" is mounted as "/home/joe", and "/home/joe/code" shows up in the file being debugged, then there is really no good way to get the full windows path.

However, if a path starts with "/" or "\", then it is probably a safe bet that it is absolute.

[MortenMacFly]

How: fstab, just like under Unix.

That's bad. I know fstab but I wouldn't want to parse the fstab file out of a debugger session just to get the full path. :-(
Or what do you (Thomas) think about that?!

However, if a path starts with "/" or "\", then it is probably a safe bet that it is absolute.

This part I don't get. You say hat the path can be something like /home/homer_j/src which points to C:/whatever/home/homer_j/src So why would it be safe to assume that it's an absolute path? Because it fact it is not...?!

[thomas]

That's bad. I know fstab but I wouldn't want to parse the fstab file out of a debugger session just to get the full path. :-(

I wouldn't either, this is beyond our scope. We are writing a user level program, not an operating system. fstab is not our business.

In that case, it's just bad luck, I'd say. Sad as it is, but we can't make it work everywhere under all configurations. It is already quite tough as it is now, and enough things don't work properly already, having to deal with normal filesystem paths using two different path separators and different quotation rules, UNC paths, Windows Unicode paths (which of course are "special" too), the "standard" Cygwin and MSYS paths, and whatever.
At some point, and mount points are such a point, you have to say "sorry, we tried, but...".

[crc1021]

This part I don't get. You say hat the path can be something like /home/homer_j/src which points to C:/whatever/home/homer_j/src So why would it be safe to assume that it's an absolute path? Because it fact it is not...?!

It is neither safe or unsafe, I just thought it would be the best guess at translation.  The worst that could happen is what it does now which is not display the file.

For the record, I was not saying c::b should even try to parse fstab or (cygwin mounts), that seems to extreme to me also.