0

After compiling a simple program as such with Mingw-w64:

#include <stdio.h>

int main(int argc, char** argv) {

        printf("hello world");
        return 0;
}

By running:

gcc -g test.c

If I try executing gdb on the resulting executable file by running:

gdb ./a

I get this output:

GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-msys".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Traceback (most recent call last):
  File "<string>", line 3, in <module>
ModuleNotFoundError: No module named 'libstdcxx'
/etc/gdbinit:6: Error in sourced command file:
Error while executing Python code.
Reading symbols from ./a...

Furthermore, if I try setting a breakpoint and then running the program, I get a couple of warnings and then the process gets aborted.

(gdb) break main
Breakpoint 1 at 0x1400015a8: file main.c, line 5.
(gdb) run
Starting program: /c/Users/gianm/Desktop/a
[New Thread 17704.0x2d54]
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1400015a3

Command aborted.

This used to work just fine just until a month ago, but now it is exhibiting this weird behaviour to which I can't seem to find a solution for.

If it can be of any help, here's my configurations:

(gdb) show configuration
This GDB was configured as follows:
   configure --host=x86_64-pc-msys --target=x86_64-pc-msys
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --with-expat
             --with-gdb-datadir=/usr/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/lib/gdb (relocatable)
             --without-libunwind-ia64
             --with-lzma
             --without-babeltrace
                             --without-intel-pt
             --with-mpfr
             --without-xxhash
             --with-python=/usr (relocatable)
             --without-guile
             --disable-source-highlight
             --with-separate-debug-dir=/usr/lib/debug (relocatable)
             --with-system-gdbinit=/etc/gdbinit

("Relocatable" means the directory can be moved with the GDB installation
tree, and GDB will still find it.)

Not sure if it is relevant, but I'm running msys2's implementations of gcc and gdb from Windows Powershell (I've added C:\msys64\usr\bin and C:\msys64\mingw64\bin to my path system variable).

EDIT: Here's the content of etc/gdbinit

python
import sys
sys.path.insert(0, sys.path[0] + '/../../gcc-9.3.0/python')
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
end
Gian
  • 327
  • 2
  • 8
  • For the `ModuleNotFoundError` problem, it looks like you have some bad configuration in your `/etc/gdbinit` file. And regarding the breakpoint problem, I think your executable has ASLR enabled, and this works with gdb only since version 10. – ssbssa Apr 22 '21 at 10:56
  • Any ideas on how to go about solving this possible configuration problem? Regarding the breakpoint,I'm not sure that that's the problem, since this used to work. Also, when searching for a solution for this problem I've stumbled upon this https://stackoverflow.com/questions/50819704/cannot-insert-breakpoints-addresses-with-low-values This poster had a similiar problem which was actually caused by ASLR being enabled. For that reason, the instruction addresses' values where really low, while those in my disassembly don't look like that. I've tried following the accepted solution, unsuccessfully. – Gian Apr 22 '21 at 11:16
  • You have to check this `gdbinit` file at line 6, like the error says. Without seeing it there isn't much else we can do here. And what does `objdump.exe -x YOUR_EXECUTABLE.exe |grep DllCharacteristics` output? If flag `0x40` is set, then ASLR is enabled. – ssbssa Apr 22 '21 at 11:33
  • @ssbssa I've added /etc/gdbinit to the original post. The value of that flag on my exe seems to be 0x00000160. – Gian Apr 22 '21 at 16:13
  • Does that path exist on your system?: `sys.path[0] + '/../../gcc-9.3.0/python'`. And 0x160 includes 0x40, so ASLR is enabled, and you need a gdb 10. – ssbssa Apr 22 '21 at 16:18
  • I've solved the problem, but I'm not really sure on why the problem existed in the first place. I actually already had gdb 10(.1.2) installed and it actually worked. That said, I also had gdb 9 installed, as shown by the outputs that I posted. gdb9 was installed in the msys64 directory, while gdb10 was installed in the mingw64 directory. As I said in the first post, I've added both to my path, and msys64 had an higher priority, so typing gdb in powershell called gdb 9, which had some issues (maybe some weird bug?). I don't get why gdb was installed twice, but fix was as simple as pacman -R gdb – Gian Apr 23 '21 at 07:06
  • Do you use the MSYS2 executables from `C:\msys64\usr\bin` in powershell as well? If not, you don't need it in the path system variable. – ssbssa Apr 23 '21 at 07:23

0 Answers0