On 24/07/2020 21:37, Keith Marshall wrote: > I've now got a working build (running in a Win7 VM) > > $ gdb --config > This GDB was configured as follows: > configure --host=mingw32 --target=mingw32 > --with-auto-load-dir=$debugdir:$datadir/auto-load > --with-auto-load-safe-path=$debugdir:$datadir/auto-load > --with-expat > --with-gdb-datadir=C:/MinGW/share/gdb (relocatable) > --with-jit-reader-dir=C:/MinGW/lib/gdb (relocatable) > --without-libunwind-ia64 > --without-lzma > --without-babeltrace > --without-intel-pt > --with-mpfr > --without-xxhash > --with-python=C:/Python27 > --without-guile > --disable-source-highlight > --with-separate-debug-dir=C:/MinGW/lib/debug (relocatable) > --with-sysroot=C:/MinGW (relocatable) > --with-system-gdbinit=C:/MinGW/... (relocatable) Eli, irrespective of support for Python relocation, I noticed that your build configuration also differs from mine, w.r.t. --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? 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. 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. (and, I guess it's unlikely that the application's support team will be able to shed any further light on this unhelpful diagnostic). 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 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. -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20200729/739e8cea/attachment.sig>
Fork