GDB doesn't have pretty-print

[BetoQA]

Being pretty-print one of the essential tools at time of debugging, since it makes the variables easy to read.

I would like to know if in a future version pretty-print would be implemented within gdb of w64devkit?

w64devkit is a powerful portable tool and easy to install: if it will has pretty-print it would be even more wonderful.

[skeeto]

Hmmm, do you know how this is enabled at compile time? As far as I can tell, this configuration is undocumented. There are hints that it requires Python. If so, then unfortunately this is off the table. Linking against libpython isn't possible because CPython does not currently support cross-compilation targeting Windows. I have a hard rule about building everything from source, and besides, I probably couldn't coax GDB into linking against an official MSVC build.

In your first screenshot, I'm guessing it works since it's running atop the MSYS2 ecosystem.

[BetoQA]

It's a shame, I didn't think it was more complex than I was thinking.

The first screenshot: it's the result of having installed mingw64 for windows: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/

[Peter0x44]

I checked the toolchain linked there, and indeed it doesn't depend on msys2 at all. For some reason the zip includes a "build-info.txt" file that mentions python 2 was built with a few patches for this to work However, I think this definitely wasn't cross-compiled due to the fact windows paths exist in this file. I'll attach it in case it's useful. build-info.txt

I seemingly see some information claiming it is possible to link to a msvc-built libpython dll, using gendef to generate some def file. This seems feasible although I'm not certain about it, and regardless it definitely isn't ideal.

It looks like python is also needed for gdb -tui which is quite useful, and pretty-printing is definitely also somewhat important. If you attempt to print the value of an std::string without it, you get the extremely readable and concise:

$2 = {_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
    _M_p = 0x33627ffad0 "bruh"}, _M_string_length = 4, {_M_local_buf = "bruh\000\001\000\000ï\023ryö\177\000",
    _M_allocated_capacity = 1101264155234}}

[Peter0x44]

Apparently one of the issues regarding CPython is that the gdb build script runs python-config, which needs to run python itself. This is obviously a problem for build != host.

https://sourceware.org/gdb/wiki/CrossCompilingWithPythonSupport

A potential solution is outlined here. This seems like an avenue to look in to for this.

(All such a nightmare compared to lua, which would be trivial... Oh well)

[skeeto]

Perhaps something to explore if CPython could ever be cross compiled, but even now I get "cross build not supported for x86_64-w64-mingw32" if I attempt it. (Just checking if anything changed the last couple years.)

All such a nightmare compared to lua, which would be trivial...

Yeah, it's a shame they didn't go with Lua. As embedded programming language, Python is a terrible guest.

[Peter0x44]

msys2 appears to have some patches working around this: https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-python/0004-configure-add-MACHDEP-and-platform-on-MINGW.patch maybe the fork of CPython it uses could be useful for us I can't really say I have much interest in figuring which of these 149!!!! patches is relevant to us it would be a really big task