#909 Codeblocks Patch for GDB Cygwin exe support

[Andrew Cottrell]

Summary: Patch to add Cygwin GDB support for debugging an EXE using the Cygwin GDB. The issue is that Cygwin path manglining w.r.t. pre appended "/cygdrive/".
PC DETIALS:
===========
OS: Windows 10 v1909 x64
Compiler: Cygwin 64 bit
Code Blocks: 17.12 and SVN below
Name : Code::Blocks
Version : svn-r11927
SDK Version : 1.46.0
Scintilla Version: 3.7.5
Author : The Code::Blocks Team
E-mail : info@codeblocks.org
Website : http://www.codeblocks.org

        wxWidgets Library (wxMSW port)
        Version 3.1.3 (Unicode: wchar_t, debug level: 1),
        compiled at Nov  1 2019 18:53:26

        Runtime version of toolkit used is 10.0.

GDB/CODEBLOCKS PROBLEM:

....SNIP...
[debug]Command-line: C:\cygwin64\bin\gdb.exe -nx -fullname -quiet -args C:/Win_Build/src/games/APP_EXE/bin/Debug/APP_EXE.exe
....SNIP...
[debug]Starting program: /cygdrive/c/Win_Build/src/games/APP_EXE/bin/Debug/APP_EXE.exe

Child process PID: 13808

[debug][New Thread 13808.0x1090]
[debug][New Thread 13808.0x42c]
[debug]Thread 1 "APP_EXE" hit Breakpoint 2, main (argc=1, argv=0xffffcc20) at C:/Win_Build/src/games/APP_EXE/main.cpp:18
[debug]/cygdrive/c/Win_Build/src/games/APP_EXE/main.cpp:18:537:beg:0x100468294
[debug]>>>>>>cb_gdb:

Cannot open file: /cygdrive/c/Win_Build/src/games/APP_EXE/main.cpp
At /cygdrive/c/Win_Build/src/games/APP_EXE/main.cpp:18

NOTE: I can run the app if I do not set a breakpint in a file!!!

INVESTIGATION:

The problem appears to be in the following codeblocks code:
\src\sdk\cbplugin.cpp => line 353 is where the "Cannot open file:" text is.
=> line 330 is:
wxString unixfilename = UnixFilename(filename);
which could be the problem as line 339 fails based
on the unixfilename being vaild, but not is NOT IMHO
with regards to how codeblocks understands filenames

\src\sdk\globals.cpp => line 228 is:
    wxString UnixFilename(const wxString& filename, wxPathFormat format)
        where the functio9n does not handle the CYGWIN filename:
            /cygdrive/c/Win_Build/src/games/APP_EXE/main.cpp:18
        as it is nether a valid Unix filename or a Windows filename,
        but a CYGWIN filename.

Info from codelite (https://github.com/eranif/codelite/blob/dc050491bb69f4b6a38231d1fdfab524e529df8e/Debugger/dbgcmd.cpp):
// By default we use the 'fullname' as our file name. however,
// if we are under Windows and the fullname contains the string '/cygdrive'
// we fallback to use the 'filename' since cygwin gdb report fullname in POSIX / Cygwin paths
// which can not be used by codelite

FIX:

diff a/src/sdk/globals.cpp b/src/sdk/globals.cpp
245,267c245,249
< if (strncmp(result, "/cygdrive/", 10) == 0)
< {
< // Needed if debugging a Cygwin build app in codeblocks. Convert GDB cygwin filemname to mingw filename!!!!
< // /cygdrive/x/... to c:/...
<
< wxString tmpfilename = filename;
< tmpfilename.Remove(0,11);
<
< result.Clear();
< result.Append(filename[10]);
< result.Append(_T(":"));
< result.Append(tmpfilename);
<
< // Manager::Get()->GetLogManager()->Log(F(_T("CYGWIN filename detected. %s => '%s'"), filename, result));
< }
< else
< {
< result.Replace(wxT("/"), wxT("\"));
< while (result.Replace(wxT("\\"), wxT("\")))
< ; // loop for recursive removal of duplicate slashes
< if (unc_name)
< result.Prepend(wxT("\"));
< }

---

    result.Replace(wxT("/"), wxT("\\"));
    while (result.Replace(wxT("\\\\"), wxT("\\")))
        ; // loop for recursive removal of duplicate slashes
    if (unc_name)
        result.Prepend(wxT("\\"));

[Teodor Petrov]

Can you post a diff -u patch? This one doesn't apply.

Are the paths in the callstack window showing correctly (without the cygwin prefix)?
I'm not sure that changing UnixFilename is a good idea. I'd rather prefer if the change is more local to the debugger. UnixFilename is something really global.

Calling strncmp on a wxString object is not really good idea. Probably you want to use the StartsWith() method.

[Andrew Cottrell]

I have moved the changes so that they are only applicable for the CDB debugger and now use StartsWith().
I had to update the patch as I found another directory mangling issue when stepping into a library (DLL) built with debug where the source was in the /usr/src/debug/... directory. The code for this is NOT nice as I did not want to make it generic and search all of the widnwos drives to see where CYGWIN is installed at run time and as such I just check a few drives. If this is not accpetable then please advise what path I should go down to get the patch approved.

New diff -U file attached.

[Teodor Petrov]

There is a registry entry for this as far as I know. And we already have code which reads it. I don't know where it is though or if this is really the case, I've never used cygwin.

[Teodor Petrov]

Another note: I've search for cygwin in the code of the debugger plugin and I've found plenty of places which try to handle cygwin paths. For some reason they are failing. I think it is better to fix those instead of adding more cygwin only code.

[Andrew Cottrell]

Found the registy code in the gdb_driver.cpp file and it looks like it has a few issues, these being:
a) Cygnus Systems folded over 20 years ago and the current key does not match the keys in the current Cygwin code (https://github.com/mirror/newlib-cygwin/blob/30782f7de4936bbc4c2e666cbaf587039c895fd3/winsup/utils/path.cc) The change was made 10 years ago, so I will update the keys.
b) Does not support \usr and other directories that are needed when stepping into a library build with debug enabled. I will move/merge the code for this.

I will work on this over the next few days,

[Andrew Cottrell]

Updated patch. The diff is hard to read. The DetectCygwinMount() was updated with the code from compilerCYGWIN.CPPCompilerCYGWIN::AutoDetectInstallationDir() function. The CorrectCygwinPath() has been updated to support a number of Cygwin directory mangaling and normal windows directoires (along with files).

The g_EscapeChar code is a doosy as it appears to be crazy, but it is needed for some reason as if it is not there then the GDB debugging does not work 100% as expected.

I could probably optimise the code, but for how many people use it and how slow it is I do not think it is worth the time & effort.

[Andrew Cottrell]

This diff file is a bit easier to read.

[Teodor Petrov]

Some comments;
1. Please use c++ comments only, it makes disabling parts of the code easier
2. Keep in mind that CorrectCygwinPath is called in a really hot path in the debuger
3. Keep in mind that there could be paths in the middle of the line, are you detecting them?
4. The thing which calls cygpath.exe needs an explanation for non-cygwin users. What does it do?
5. What is this fix me - // FIXME: change cypath => fullName?
6. Would it be possible to write some tests for this cygwin conversion function?

2 and 3 are the most worrisome. Would it be possible to not call it from the ParseOutput function, but from every place which is known to parse file paths. A start could be the ParseOutput function in the backtrace command. See the GdbCmd_Backtrace::ParseOutput function. I know that it will be a lot more work and it will be annoying and bug prone, but I think it will be the better solution in the long term.

Thanks for the contribution.

BTW: Do you know if the compiler detection code is correct? There were reports in the past about failures I think.

[Andrew Cottrell]

Thanks for the feedback. I will have a look at the comments in relation to the code in more detail over the next few days.
The compiler detection code is okay and is where I borrowed the changes for DetectCygwinMount() from as it works correctly for the new and hopefully the old registry entries.

[Andrew Cottrell]

I do not have access to the forums. I have tried and have not received any emails for the two accounts I have tried to create. There is a a new forum post where the user cannot get the Cygwin GDB working. The forum reference is http://forums.codeblocks.org/index.php/topic,23649.0.html
Any chance of adding a note/link that the Cygwin GDB debugger is not working at the moment or a link to this ticket as a WIP.

I have tested the updated changes I have done to ensure that there are no side affects I can see as I am not familiar with the GDB interactions. I have updated the changes to be more focused like the Codelite Cygwin path changes with teh exception of the stacktrace as it is useable as it is when I hit a signal() and GDB catches it.
The changes I have done based on the feedback are :
1) Done.
2)The original position has been there for 10 yrs andhas been broken for that long, so looks like very few people use Cygwin and the people that try and fail then move to mingw that works. I looked at Codelite Cygwin path changes and as best I could made similar changes in similar areas (if I have understood the code, which may not be the case) with the exception of the stacktrace as it is useable as it is when I hit a signal() and GDB catches it.
3) The changes hopefully cater for this now as they are focused in particular GDB responses that have a filename (except the call stack).
4) The code is only applicable for CYGWIN and hopefully the comments are enough. Codlite also calls the cygpath.exe as this is where I got the call from to do the main path conversion as Codelite worked out of the box with Cygwin GDB.
5) Removed
6) The GDB unit tests have not been chnaged in a long long time, but changes have been mode. I do not have time to install the unittest++ and write the tests. I did create a small test app and it passed all of the paths came up with.

Attached is the updated patch and the updated gdb_driver.cpp.

[Morten MacFly]

If you try to register once again and tell me the email you've used I can manually active the account. But its strange anyways.

[Teodor Petrov]

6) Just write the tests to look like unittest++ functions and I'll make them compile and pass. :)

I'll check the reset of the changes later. I've also sent a message to an admin to see if we can get you access to the forum.

[Teodor Petrov]

Fixed in master/trunk