> From: Keith Marshall <keith****@users*****> > Date: Wed, 29 Jul 2020 20:36:20 +0100 > > --with-guile vs. --without-guile > --with-xxhash vs. --without-xxhash > --with-lzma vs. --without-lzma > > I've since discovered that xxhash is rather easy to support, so I've now > added --with-xxhash for my build. I could also, rather easily, support > the --with-lzma option, since I already have liblzma; I chose to disable > it because the GDB manual suggests that it is only useful when debugging > ELF binaries -- which Windows PE-COFF binaries (obviously) are not. Is > there any strong use case for enabling it anyway? The lzma support is indeed not useful for native Windows debugging. But a MinGW GDB is not just a native debugger, it can also be used for debugging remote targets via gdbserver, and in that case it can debug other targets, including ELF-based ones. That is the reason all those *read.c files are compiled into the MinGW build, even though only coff-pe-read.c is needed for native debugging. > I've explicitly specified --without-guile, simply because I do not have > any MinGW guile implementation installed. I don't intend to pursue this > further, unless anyone cares enough to offer a strong justification for > me to do so. Guile extensions are rarely if ever used in GDB. About the only non-trivial use I've seen is to debug Guile itself. And porting Guile to Windows is not an easy job. So I think leaving Guile out would not be a problem in practice. > One aspect, which is not apparent in the above configuration listing, is > TUI support. I've taken some time out, to build ncurses-6.2 for MinGW, > and so enable this support; it works ... sort of ... but does exhibit > some instability. Specifically: if (on my Win7 VM) I start > > $ gdb --tui > > then subsequently > > (gdb) tui disable > > the curses windows close, but the (gdb) prompt is not restored; when I > then press the <RETURN> key, GDB crashes, with the diagnostic > > This application has requested the Runtime to terminate it in an > unusual way. Please contact the application's support team for > more information. Yes, I see this in GDB 9.1 as well. It doesn't happen in GDB 8.x, and not in what is about to be GDB 10.1, though. > FWIW, this same instability is evident with Eli's ncurses-5.9, from the > corresponding ezwinport, and also with Erwin Waterlan's ncurses-6.0, as > published on the old MinGW SourceForge FRS. It does not appear to be in > evidence if GDB is started normally, and TUI mode started thereafter > > $ gdb > ... > (gdb) tui enable > ... > (gdb) tui disable > (gdb) q The TUI parts of GDB got destabilized in v9, due to massive refactoring of the code. Some of the resulting bugs were fixed before GDB 9.1 was released, but some only after that, so I expect some dark corners in 9.2. The above is not the usual way the TUI is activated, you usually start GDB with the --tui command-line argument, and never turn off TUI during the session. > However, I've done very little testing of the TUI mode capability; in > fact, I don't like it very much ... although I do regret the demise of > Insight, as a GDB user interface. I myself use TUI only when I need to debug the TUI code. When I need a nice UI for GDB, I use Emacs. But I think the TUI is quite functional in 9.x, so I wouldn't recommend building without it. Someone might actually like this feature.
Fork