Quantcast
Channel: Active questions tagged gcc - Stack Overflow
Viewing all articles
Browse latest Browse all 22000

Issue when debugging with gdb after compiling with the MSYS2 MinGW-w64 gcc (crtexe.c, No such file or directory)

$
0
0

I'm having this "issue" with gcc and gdb, which by itself isn't a real problem but it still annoys me and I want to understand why it's happening and how to solve it. First I want to apologize because English is not my native language.

tl;dr: When I debug a file compiled with the MSYS2 MinGW-w64 gcc and I get to the last line of main and click 'Step over' (on VS code) or type the 'next' command (running gdb on the shell) I get an error indicating that the file 'crtexe.c' cannot be opened or be found. It doesn't cause me any trouble but it's annoying. Also, it doesn't happen when the official MinGW-w64 gcc compiler is used instead.

To put you in context, I'm doing the Harvard's CS50 course but I always want to dig deeper and end up spending much more time in topics don't covered by the course itself, so now I'm on Windows 10 with MSYS2, Mingw-w64, and VS Code installed. In the beginning, I started only with MinGW-w64 that I downloaded from the official website but then I realized that gcc was outdated and that installing libraries was quite complicated. So after some Google searches, I discarded the 'official' MinGW-w64 and ended up with MSYS2 and the MinGW-w64 built by them. I had the task.json, launch.json, and c_cpp_properties.json from VS Code already set up so I only changed the paths to gcc and gdb of MSYS2 and I was good to go.

But now I've noticed an error that wasn't happening before with the 'official' version of MinGW-w64. When I'm debugging a program (as simple as a 'helloworld') and I get to the last line of main (the final curly bracket) and click 'Step Over', this error message appears in VS Code:Debugging error VS Code, gdb

I need to press 'Step Over' again (and receive the same error message again) two more times to finally end the program.

At first, I thought it was VS Code fault so I ran gdb directly from the shell and stepped over the code with the 'next' command, and I got the same error at the end:

(gdb) nextHello world!6   }(gdb) next__tmainCRTStartup ()    at D:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:337337     D:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c: No such file or directory.(gdb) next338     in D:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c(gdb) next[Thread 4232.0x1a94 exited with code 0][Inferior 1 (process 4232) exited normally]

That made me think it was gdb the one causing the problem. But finally, after testing with both gcc and gdb from both the official MinGW-w64 and MSYS2's MinGW-w64 I concluded that the one with the issue was MSYS2 MinGW-w64 gcc. I can compile with the official mingw-w64 gcc and debug with gdb of msys2 and it works fine. But in reverse, if I compile with MSYS2 MinGW-w64 gcc and debug with the official MinGW-w64 gdb, the problem appears again.

When I compile using the official MinGW-w64 gcc and then debug it, the final gdb lines are these:

Hello world!6   }(gdb) next0x00000000004013c7 in __tmainCRTStartup ()(gdb) nextSingle stepping until exit from function __tmainCRTStartup,which has no line number information.[Thread 9436.0x1748 exited with code 0][Inferior 1 (process 9436) exited normally]

which doesn't translate into an error message in VS Code.

As I understand, that function (__tmainCRTStartup) is the one that starts every C program and also kills the process when it's over. I know I can simply ignore that error. But I hate error messages hehe. Besides, why if I'm stepping over the code, the debugger tries to step into that function's source code? I'd understand if I'm trying to step into, but that's not the case. Why is this happening and what can I do to fix it? (besides clicking 'Continue' instead of 'Step Over' when I'm at the end of main).

Thank you!


Viewing all articles
Browse latest Browse all 22000

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>