Re: Time for a MinGW-GDB Upgrade?

Keith Marshall <[email protected]> Wed, 29 Jul 2020 20:36:20 +0100
Newsgroups	gmane.comp.gnu.mingw.user
Organization	MinGW.org Project
Message-ID	<[email protected]>
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

_______________________________________________
MinGW-Users mailing list
[email protected]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.osdn.me/mailman/listinfo/mingw-users
Also: mailto:[email protected]?subject=unsubscribe
signature.asc (application/pgp-signature, 833 B)