GCC is missing support for gcodeview

Question

GCC is missing support for gcodeview

Febbe opened this issue 2 years ago · 9 comments

Description / Steps to reproduce the issue

When compiling something on windows/msys2/UCRT64 with the -gcodeview option, to generate windbg pdb files, the compilation fails. The installed GCC does not support gcodeview, even when it should, because it compiles for windows.
See https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

Maybe, gcc must be built with an additional flag to support it.

Steps to reproduce:

Open UCRT
pacman -Syuu mingw-w64-ucrt-x86_64-gcc mingw-w64-ucrt-x86_64-gdb 13.2-2
gcc -gcodeview path/to/some/source-file

Expected behavior

It compiles

Actual behavior

$ gcc -gcodeview
gcc.exe: error: unrecognized debug output level 'codeview'
gcc.exe: fatal error: no input files
compilation terminated.

Note that clang on clang64 compiles just fine.

Verification

I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MINGW64_NT-10.0-22621

MINGW environments affected

Are you willing to submit a PR?

No response

Answer 1 · 2023-06-21T17:02:40.000Z

Requires gcc-14, so probably not solvable for now.

Answer 2 · 2023-06-22T08:33:01.000Z

Is this really just gcc-mirror/gcc@2f7e7bf ?

We can certainly backport that if wanted.

edit: more context: https://inbox.sourceware.org/gcc-patches/a22433f5-b4d2-19b7-86a2-31e2ee45fb61@martin.st/T/

Answer 3 · 2023-06-22T09:12:47.000Z

I can wait until gcc-14 is released :).

Answer 4 · 2023-12-18T13:06:10.000Z

I believe the backport may have been premature - The -gcodeview option is reportedly not fully implemented yet, and produces incomplete debug information that results in an error when used with Visual Studio's debugger "A matching symbol was not found in this folder"

Answer 5 · 2023-12-18T20:58:27.000Z

Some more info for future reference, afer some digging in the mailing lists:

The current state in gcc is incomplete, and gcc 14 will be released that way, so this backport just gives us what 14 will give us: https://patchwork.ozlabs.org/project/gcc/patch/20221027033829.22918-1-mark@harmstone.com/#3006911
There is some pending work to improve things: https://patchwork.ozlabs.org/project/gcc/list/?series=380014 but as stated in https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634490.html that too is just a start and far from complete.

Since gcc 14 will have the option as we have it now, I think the backport does no harm.

Sorry @TheShermanTanker for the false hopes :)

Answer 6 · 2023-12-19T05:50:49.000Z

Sigh, looks like the JDK will have to continue using DWARF debuginfo for now. Thanks for the info, no worries

Answer 7 · 2023-12-20T11:24:02.000Z

Sigh, looks like the JDK will have to continue using DWARF debuginfo for now. Thanks for the info, no worries

You could use clang / llvm instead. They support -gcodeview

Answer 8 · 2023-12-20T14:32:15.000Z

Sigh, looks like the JDK will have to continue using DWARF debuginfo for now. Thanks for the info, no worries

You could use clang / llvm instead. They support -gcodeview

That would require me to throw away all the work I've done with porting the JDK to work with the primary compiler for MSYS2 (gcc), which I unfortunately cannot do

Answer 9 · 2023-12-26T14:02:35.000Z

That would require me to throw away all the work I've done with porting the JDK to work with the primary compiler for MSYS2 (gcc), which I unfortunately cannot do

What do you mean with primary compiler?
one of ucrt64/bin/gcc / mingw64/bin/gcc or the one in /bin/gcc directly?
For the first, just install clang64/bin/clang, it supports nearly all GCC intrinsics and compile flags.
Regarding the latter, you could try to compile llvm with gcc and then compile the jdk with the newly created clang.