This is a problem on cygwin. Launch the cygwin gdb, give it an windows absolute path to an executable. From the output you'll see the symbol table is loaded, so gdb understands the path. Yet, when attempting to run the program, it fails to create the process. A previous version, 9.2-1, works. To reproduce the problem, run the following shell script from a cygwin terminal. echo Create main.c cat >main.c <<END #include <stdio.h> int main(int argc, char**argv) { printf("Hello world!"); } END echo Compile main.c to main.exe gcc main.c -o main cmd="gdb $(cygpath -wa main.exe)" echo $cmd $cmd <<END run q END
I forgot to mention that this bug is fairly important because it prevents eclipse from debugging cygwin applications.
Using a Windows Eclipse and Winows Java with Cygwin executables is bound to encounter problems like this, which cannot be generically solved in Cygwin. Passing Windows-style paths to POSIX API functions which take a pathname generally works. But if an executable (in this case, gdb) does some internal manipulation on the pathname, assuming it's in POSIX-style, you get problems. The simple solution is to write a wrapper around gdb, which takes a Windows-style path, and converts it using cygpath to POSIX-style before passing it to gdb. The complex solution is to modfiy gdb so it identifies the style of path before manipulating it appropriately, but some one who cares about this edge-case will have to write it.
Thanks Jon for the analysis. > but some one who cares about this edge-case will have to write it. I think that is the problem we are facing now as to who will solve this problem. For the last ~20 years it turns out that CDT was relying on undefined behaviour in Cygwin/GDB that changed in GDB 10. We are going to track that work in CDT here https://github.com/eclipse-cdt/cdt/issues/228 but at the moment no one is allocated to it, but here is hoping that someone steps forward. I have given guidance of where someone could start in CDT.
Note: This is a regression in gdb 10 and later.
I bisected this, which lands on : # first bad commit: [727b7b1864973c2645a554727afd0eaf1303673a] Sync config, include and libiberty with GCC Looking at: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=727b7b1864973c2645a554727afd0eaf1303673a#patch4 This makes perfect sense, but doesn't really offer a lot of immediate clues how to fix it. There's presumably some logic in gdb/windows-nat which uses those macros (probably IS_ABSOLUTE_PATH given the reported problem), who's behaviour is changed by this commit.
Thanks Jon for the bisect - that points back at GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570 which implies that it was a deliberate change to fix that use case by stopping having support for Windows separators and now that GDB has sync'ed to GCC's version we see the effect on GDB on Cygwin.
Yes, the way to fix this is not to try to revert that commit, but, as I mentioned previously, to add explicit handling for Windows-style paths on Cygwin in the place where this change makes it go wrong.