GDB 15.0.91 available for testing

GDB 15.0.91 available for testing

[Joel Brobecker]

Hello,

I have just finished creating the gdb-15.0.91 pre-release.
It is available for download at the following location:

    https://sourceware.org/pub/gdb/snapshots/branch/gdb-15.0.91.tar.xz

A gzip'ed version is also available: gdb-15.0.91.tar.gz.

Please give it a test if you can and report any problems you might find.

On behalf of all the GDB contributors, thank you!
-- 
Joel Brobecker

Building GDB 15.0.91 on MinGW: CPPFLAGS

[Eli Zaretskii]

> From: Joel Brobecker <brobecker@adacore.com>
> Date: Sat,  1 Jun 2024 08:59:07 -0700 (PDT)
> X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED,
>  DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,
>  SPF_PASS, TXREP,
>  T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
> 
> Hello,
> 
> I have just finished creating the gdb-15.0.91 pre-release.
> It is available for download at the following location:
> 
>     https://sourceware.org/pub/gdb/snapshots/branch/gdb-15.0.91.tar.xz
> 
> A gzip'ed version is also available: gdb-15.0.91.tar.gz.
> 
> Please give it a test if you can and report any problems you might find.

I'm trying to build this pretest, and I need help with setting
non-standard CPPFLAGS.  (I need that to specify the
D__USE_MINGW_ANSI_STDIO=1 preprocessor option, because libctf uses the
%z format which needs that.)

I thought it was enough to specify CPPFLAGS in the top-level configure
command:

  CFLAGS='-O2 -gdwarf-4 -g3' CXXFLAGS='-O2 -gdwarf-4 -g3' CPPFLAGS='-D__USE_MINGW_ANSI_STDIO=1' ./configure ...

However, it sounds like this is not working, because "make V=1"
doesn't show the option on the GCC command line.  Here's an example:

  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D_GNU_SOURCE -I. -I./../include -I./../bfd -I../bfd -DNOBFD=0 -Id:/usr/include -std=gnu99 -Wall -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long -O2 -gdwarf-4 -g3 -MT libctf_la-ctf-archive.lo -MD -MP -MF .deps/libctf_la-ctf-archive.Tpo -c ctf-archive.c -o libctf_la-ctf-archive.o

Note that CFLAGS I specified to the top-level configure _are_ used.
Why doesn't the same happen with CPPFLAGS?  Is that some libtool trick
or something?  I do see in top-level Makefile this:

  CPPFLAGS_FOR_BUILD = -D__USE_MINGW_ANSI_STDIO=1

PLEASE HELP, I cannot move on without unlocking this mystery.  (And
yes, there are other issues with this build, so I do have more work on
it.)

TIA

Re: Building GDB 15.0.91 on MinGW: CPPFLAGS and libctf

[Eli Zaretskii]

> Date: Thu, 06 Jun 2024 23:16:31 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org
> 
> I thought it was enough to specify CPPFLAGS in the top-level configure
> command:
> 
>   CFLAGS='-O2 -gdwarf-4 -g3' CXXFLAGS='-O2 -gdwarf-4 -g3' CPPFLAGS='-D__USE_MINGW_ANSI_STDIO=1' ./configure ...
> 
> However, it sounds like this is not working, because "make V=1"
> doesn't show the option on the GCC command line.  Here's an example:
> 
>   libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D_GNU_SOURCE -I. -I./../include -I./../bfd -I../bfd -DNOBFD=0 -Id:/usr/include -std=gnu99 -Wall -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long -O2 -gdwarf-4 -g3 -MT libctf_la-ctf-archive.lo -MD -MP -MF .deps/libctf_la-ctf-archive.Tpo -c ctf-archive.c -o libctf_la-ctf-archive.o
> 
> Note that CFLAGS I specified to the top-level configure _are_ used.
> Why doesn't the same happen with CPPFLAGS?  Is that some libtool trick
> or something?  I do see in top-level Makefile this:
> 
>   CPPFLAGS_FOR_BUILD = -D__USE_MINGW_ANSI_STDIO=1
> 
> PLEASE HELP, I cannot move on without unlocking this mystery.  (And
> yes, there are other issues with this build, so I do have more work on
> it.)

Hmm... no responses.  I'm somewhat disappointed, since I thought the
pretest is important, as we want to release soon...

Anyway, I've used my old trick of working around Libtool's "wiseguy"
type of second-guessing what I want, by saying

   CC='gcc -D__USE_MINGW_ANSI_STDIO=1'

at configure time.  That did force Libtool to use that flag, but
didn't solve the problems with the %z format.

Turns out the problem was elsewhere.  ctf-impl.h says this:

  #define _libctf_printflike_(string_index,first_to_check) \
      __attribute__ ((__format__ (__printf__, (string_index), (first_to_check))))

and then uses this to declare ctf_dprintf:

  _libctf_printflike_ (1, 2)
  void ctf_dprintf (const char *format, ...)

The GCC manual says about this attribute:

  'format (ARCHETYPE, STRING-INDEX, FIRST-TO-CHECK)'
       The 'format' attribute specifies that a function takes 'printf',
       'scanf', 'strftime' or 'strfmon' style arguments that should be
       type-checked against a format string.
       [...]
       The parameter ARCHETYPE determines how the format string is
       interpreted, and should be 'printf', 'scanf', 'strftime',
       'gnu_printf', 'gnu_scanf', 'gnu_strftime' or 'strfmon'.  (You can
       also use '__printf__', '__scanf__', '__strftime__' or
       '__strfmon__'.)  On MinGW targets, 'ms_printf', 'ms_scanf', and
       'ms_strftime' are also present.  ARCHETYPE values such as 'printf'
       refer to the formats accepted by the system's C runtime library,
       while values prefixed with 'gnu_' always refer to the formats
       accepted by the GNU C Library.

So using __printf__ invokes the platform's default formats, and those
don't include %z on MS-Windows.  The solution is to use __gnu_printf__
instead:

--- libctf/ctf-impl.h.~1~	2024-05-26 18:55:53.000000000 +0300
+++ libctf/ctf-impl.h	2024-06-07 14:41:48.357697100 +0300
@@ -68,7 +68,7 @@ extern "C"
    __attribute_blah__.  */
 
 #define _libctf_printflike_(string_index,first_to_check) \
-    __attribute__ ((__format__ (__printf__, (string_index), (first_to_check))))
+    __attribute__ ((__format__ (__gnu_printf__, (string_index), (first_to_check))))
 #define _libctf_unlikely_(x) __builtin_expect ((x), 0)
 #define _libctf_unused_ __attribute__ ((__unused__))
 #define _libctf_malloc_ __attribute__((__malloc__))


Where do I report libctf bugs?  Is it okay to install the above in the
GDB Git repository?

Re: Building GDB 15.0.91 on MinGW: CPPFLAGS and libctf

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: brobecker@adacore.com,  gdb-patches@sourceware.org
> Date: Fri, 07 Jun 2024 13:38:27 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> Hmm... no responses.  I'm somewhat disappointed, since I thought the
> Eli> pretest is important, as we want to release soon...
> 
> People are busy.

So am I.  Emacs 30 is about to enter the release cycle.  Still, I took
several hours of my non-existent free time to try building this
pretest, since Joel asked me to do that each time a pretest is
published.

> Eli> Where do I report libctf bugs?
> 
> Either the binutils product in bugzilla or you can email the patch to
> the binutils list.
> 
> Eli> Is it okay to install the above in the
> Eli> GDB Git repository?
> 
> Not without approval from the appropriate binutils maintainer.

Thanks, will do.

> You can also use --disable-libctf to skip it; I frequently do this.
> It's only useful in special situations anyway.

Yes, about that: I don't have babeltrace, and the configure script
says:

  babletrace support disabled; GDB is unable to read CTF data.

Does this mean libctf is not going to be used in this build?  If so,
why doesn't the configure script disable libctf automatically when
babletrace is not available?

Re: Building GDB 15.0.91 on MinGW: CPPFLAGS and libctf

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

>> You can also use --disable-libctf to skip it; I frequently do this.
>> It's only useful in special situations anyway.

Eli> Yes, about that: I don't have babeltrace, and the configure script
Eli> says:

Eli>   babletrace support disabled; GDB is unable to read CTF data.

Eli> Does this mean libctf is not going to be used in this build?  If so,
Eli> why doesn't the configure script disable libctf automatically when
Eli> babletrace is not available?

Confusingly, there are two different meanings for "CTF".

The babeltrace "CTF" is something like "common trace format".
This is controlled by options mentioning babeltrace.

The "libctf" thing is some kind of C-specific debug format.
libctf is in-tree, so --disable-libctf tells the top-level build code
that this directory should be omitted from the build.

Tom

Re: Building GDB 15.0.91 on MinGW: CPPFLAGS and libctf

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>,  brobecker@adacore.com,
>   gdb-patches@sourceware.org
> Date: Fri, 07 Jun 2024 15:39:23 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> Yes, about that: I don't have babeltrace, and the configure script
> Eli> says:
> 
> Eli>   babletrace support disabled; GDB is unable to read CTF data.
> 
> Eli> Does this mean libctf is not going to be used in this build?  If so,
> Eli> why doesn't the configure script disable libctf automatically when
> Eli> babletrace is not available?
> 
> Confusingly, there are two different meanings for "CTF".
> 
> The babeltrace "CTF" is something like "common trace format".
> This is controlled by options mentioning babeltrace.
> 
> The "libctf" thing is some kind of C-specific debug format.
> libctf is in-tree, so --disable-libctf tells the top-level build code
> that this directory should be omitted from the build.

OK, thanks for explaining.

Btw, the typo ("babletrace") in the message above is in the configure
script.

Re: Building GDB 15.0.91 on MinGW: CPPFLAGS and libctf

[Eli Zaretskii]

> Date: Fri, 07 Jun 2024 15:21:40 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> CC: gdb-patches@sourceware.org
> 
> Turns out the problem was elsewhere.  ctf-impl.h says this:
> 
>   #define _libctf_printflike_(string_index,first_to_check) \
>       __attribute__ ((__format__ (__printf__, (string_index), (first_to_check))))
> 
> and then uses this to declare ctf_dprintf:
> 
>   _libctf_printflike_ (1, 2)
>   void ctf_dprintf (const char *format, ...)
> 
> The GCC manual says about this attribute:
> 
>   'format (ARCHETYPE, STRING-INDEX, FIRST-TO-CHECK)'
>        The 'format' attribute specifies that a function takes 'printf',
>        'scanf', 'strftime' or 'strfmon' style arguments that should be
>        type-checked against a format string.
>        [...]
>        The parameter ARCHETYPE determines how the format string is
>        interpreted, and should be 'printf', 'scanf', 'strftime',
>        'gnu_printf', 'gnu_scanf', 'gnu_strftime' or 'strfmon'.  (You can
>        also use '__printf__', '__scanf__', '__strftime__' or
>        '__strfmon__'.)  On MinGW targets, 'ms_printf', 'ms_scanf', and
>        'ms_strftime' are also present.  ARCHETYPE values such as 'printf'
>        refer to the formats accepted by the system's C runtime library,
>        while values prefixed with 'gnu_' always refer to the formats
>        accepted by the GNU C Library.
> 
> So using __printf__ invokes the platform's default formats, and those
> don't include %z on MS-Windows.  The solution is to use __gnu_printf__
> instead:
> 
> --- libctf/ctf-impl.h.~1~	2024-05-26 18:55:53.000000000 +0300
> +++ libctf/ctf-impl.h	2024-06-07 14:41:48.357697100 +0300
> @@ -68,7 +68,7 @@ extern "C"
>     __attribute_blah__.  */
>  
>  #define _libctf_printflike_(string_index,first_to_check) \
> -    __attribute__ ((__format__ (__printf__, (string_index), (first_to_check))))
> +    __attribute__ ((__format__ (__gnu_printf__, (string_index), (first_to_check))))
>  #define _libctf_unlikely_(x) __builtin_expect ((x), 0)
>  #define _libctf_unused_ __attribute__ ((__unused__))
>  #define _libctf_malloc_ __attribute__((__malloc__))
> 
> 
> Where do I report libctf bugs?  Is it okay to install the above in the
> GDB Git repository?

Now reported to the Binutils bugzilla, see

  https://sourceware.org/bugzilla/show_bug.cgi?id=31863

Building GDB 15.0.91 on MinGW: gcore.c

[Eli Zaretskii]

> From: Joel Brobecker <brobecker@adacore.com>
> Date: Sat,  1 Jun 2024 08:59:07 -0700 (PDT)
> 
> Hello,
> 
> I have just finished creating the gdb-15.0.91 pre-release.
> It is available for download at the following location:
> 
>     https://sourceware.org/pub/gdb/snapshots/branch/gdb-15.0.91.tar.xz
> 
> A gzip'ed version is also available: gdb-15.0.91.tar.gz.
> 
> Please give it a test if you can and report any problems you might find.

I get a warning compiling gcore.c:

       CXX    gcore.o
     gcore.c: In function 'int objfile_find_memory_regions(target_ops*, find_memory_region_ftype, void*)':
     gcore.c:563:36: warning: 'temp_top' may be used uninitialized in this function [-Wmaybe-uninitialized]
       563 |     (*func) (temp_bottom, temp_top - temp_bottom,
	   |                           ~~~~~~~~~^~~~~~~~~~~~~
     gcore.c:563:13: warning: 'temp_bottom' may be used uninitialized in this function [-Wmaybe-uninitialized]
       563 |     (*func) (temp_bottom, temp_top - temp_bottom,
	   |     ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       564 |       1, /* Stack section will be readable.  */
	   |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       565 |       1, /* Stack section will be writable.  */
	   |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       566 |       0, /* Stack section will not be executable.  */
	   |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       567 |       1, /* Stack section will be modified.  */
	   |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       568 |       false, /* No memory tags in the object file.  */
	   |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       569 |       obfd);
	   |       ~~~~~


Suggested fix:

--- gdb/gcore.c~0	2024-05-26 18:55:53.000000000 +0300
+++ gdb/gcore.c	2024-06-06 22:43:14.518884300 +0300
@@ -528,7 +528,7 @@ objfile_find_memory_regions (struct targ
 			     find_memory_region_ftype func, void *obfd)
 {
   /* Use objfile data to create memory sections.  */
-  bfd_vma temp_bottom, temp_top;
+  bfd_vma temp_bottom = 0, temp_top = 0;
 
   /* Call callback function for each objfile section.  */
   for (objfile *objfile : current_program_space->objfiles ())

OK to install?

Re: Building GDB 15.0.91 on MinGW: gcore.c

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Joel Brobecker <brobecker@adacore.com>,  gdb-patches@sourceware.org
> Date: Fri, 07 Jun 2024 13:39:57 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> --- gdb/gcore.c~0	2024-05-26 18:55:53.000000000 +0300
> Eli> +++ gdb/gcore.c	2024-06-06 22:43:14.518884300 +0300
> Eli> @@ -528,7 +528,7 @@ objfile_find_memory_regions (struct targ
> Eli>  			     find_memory_region_ftype func, void *obfd)
> Eli>  {
> Eli>    /* Use objfile data to create memory sections.  */
> Eli> -  bfd_vma temp_bottom, temp_top;
> Eli> +  bfd_vma temp_bottom = 0, temp_top = 0;
>  
> Eli>    /* Call callback function for each objfile section.  */
> Eli>    for (objfile *objfile : current_program_space->objfiles ())
> 
> Eli> OK to install?
> 
> Ok.
> Approved-By: Tom Tromey <tom@tromey.com>

Thanks, installed:

commit e222ed2ce5b5359bfc6d8fd125534ccb507d7fb0
Author:     Eli Zaretskii <eliz@gnu.org>
AuthorDate: Sat Jun 8 10:22:03 2024 +0300
Commit:     Eli Zaretskii <eliz@gnu.org>
CommitDate: Sat Jun 8 10:22:03 2024 +0300

    gdb: Avoid compilation warning in gcore.c.
    
    See https://sourceware.org/pipermail/gdb-patches/2024-June/209726.html
    for the details.
    
    Approved-By: Tom Tromey <tom@tromey.com>

diff --git a/gdb/gcore.c b/gdb/gcore.c
index 0079662..2ab00a0 100644
--- a/gdb/gcore.c
+++ b/gdb/gcore.c
@@ -528,7 +528,7 @@ objfile_find_memory_regions (struct target_ops *self,
 			     find_memory_region_ftype func, void *obfd)
 {
   /* Use objfile data to create memory sections.  */
-  bfd_vma temp_bottom, temp_top;
+  bfd_vma temp_bottom = 0, temp_top = 0;
 
   /* Call callback function for each objfile section.  */
   for (objfile *objfile : current_program_space->objfiles ())

Building GDB 15.0.91 on MinGW: ui_out_emit_type<ui_out_type_tuple>::m_uiout

[Eli Zaretskii]

While building GDB 15.0.91 on MinGW, I see several warnings like
below:

       CXX    breakpoint.o
     In file included from ././exceptions.h:23,
		      from ././utils.h:22,
		      from ././defs.h:408,
		      from <command-line>:
     ././ui-out.h: In function 'void print_one_breakpoint(breakpoint*, const bp_location**, int)':
     ././ui-out.h:415:18: warning: 'bkpt_tuple_emitter.ui_out_emit_type<ui_out_type_tuple>::m_uiout' may be used uninitialized in this function [-Wmaybe-uninitialized]
       415 |     m_uiout->end (Type);
	   |     ~~~~~~~~~~~~~^~~~~~
     breakpoint.c:6848:36: note: 'bkpt_tuple_emitter.ui_out_emit_type<ui_out_type_tuple>::m_uiout' was declared here
      6848 |   std::optional<ui_out_emit_tuple> bkpt_tuple_emitter (std::in_place, uiout,
	   |                                    ^~~~~~~~~~~~~~~~~~

Similar warnings are emitted in disasm.c, record-btrace.c, and
symtab.c.  They are all about
ui_out_emit_type<ui_out_type_tuple>::m_uiout and line 415 in ui-out.h.

How to avoid this warning?  Does it indicate a real problem in the
code?

Re: Building GDB 15.0.91 on MinGW: ui_out_emit_type<ui_out_type_tuple>::m_uiout

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Joel Brobecker <brobecker@adacore.com>,  gdb-patches@sourceware.org
> Date: Fri, 07 Jun 2024 13:43:42 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli>      ././ui-out.h: In function 'void print_one_breakpoint(breakpoint*, const bp_location**, int)':
> Eli>      ././ui-out.h:415:18: warning: 'bkpt_tuple_emitter.ui_out_emit_type<ui_out_type_tuple>::m_uiout' may be used uninitialized in this function [-Wmaybe-uninitialized]
> Eli>        415 |     m_uiout->end (Type);
> Eli> 	   |     ~~~~~~~~~~~~~^~~~~~
> Eli>      breakpoint.c:6848:36: note: 'bkpt_tuple_emitter.ui_out_emit_type<ui_out_type_tuple>::m_uiout' was declared here
> Eli>       6848 |   std::optional<ui_out_emit_tuple> bkpt_tuple_emitter (std::in_place, uiout,
> Eli> 	   |                                    ^~~~~~~~~~~~~~~~~~
> 
> Eli> Similar warnings are emitted in disasm.c, record-btrace.c, and
> Eli> symtab.c.  They are all about
> Eli> ui_out_emit_type<ui_out_type_tuple>::m_uiout and line 415 in ui-out.h.
> 
> Eli> How to avoid this warning?  Does it indicate a real problem in the
> Eli> code?
> 
> This is a false warning.  There is no bug in gdb, only in the compiler.
> 
> The old gdb::optional had a workaround for this, but this was lost when
> we moved to std::optional.
> 
> There was a gcc bug for this but I can't readily find the correct one.

OK, thanks, I will ignore these warnings.

Building GDB 15.0.91 on MinGW: libctf.la

[Eli Zaretskii]

The generated file libctf.la looks wrong to me, where it spells out
the dependencies:

  dependency_libs=' -L/d/gnu/gdb-15.0.91/libctf/../libiberty -Ld:/usr/lib /d/gnu/gdb-15.0.91/bfd/libbfd.la /d/gnu/gdb-15.0.91/libsframe/libsframe.la -liberty d:/usr/lib/libintl.la -liconv d:/usr/lib/libiconv.la -lz'

This seems wrong on several accounts:

  . -libiberty is not after the -L option that points to GDB's
    libiberty subdirectory, but after a global system's directory
    where I have libraries.  This actually caused the link to fail,
    because I had there an old libiberty.a, and the linker complained
    about duplicate symbols
  . Both -liconv and libiconv.la are mentioned

Where do I report these libctf problems?

Re: Building GDB 15.0.91 on MinGW: libctf.la

[Eli Zaretskii]

> Date: Fri, 07 Jun 2024 15:34:47 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org
> 
> The generated file libctf.la looks wrong to me, where it spells out
> the dependencies:
> 
>   dependency_libs=' -L/d/gnu/gdb-15.0.91/libctf/../libiberty -Ld:/usr/lib /d/gnu/gdb-15.0.91/bfd/libbfd.la /d/gnu/gdb-15.0.91/libsframe/libsframe.la -liberty d:/usr/lib/libintl.la -liconv d:/usr/lib/libiconv.la -lz'
> 
> This seems wrong on several accounts:
> 
>   . -libiberty is not after the -L option that points to GDB's
>     libiberty subdirectory, but after a global system's directory
>     where I have libraries.  This actually caused the link to fail,
>     because I had there an old libiberty.a, and the linker complained
>     about duplicate symbols
>   . Both -liconv and libiconv.la are mentioned
> 
> Where do I report these libctf problems?

Now reported to the Binutils bugzilla, see

  https://sourceware.org/bugzilla/show_bug.cgi?id=31864

Building GDB 15.0.91 on MinGW: Problem with TUI

[Eli Zaretskii]

After I've succeeded to build this pretest, I've bumped into a problem
with debugging using TUI (which uses ncurses in my build).  GDB starts
okay with the -tui option, but running the debuggee fails, popping a
Windows dialog that says:

    The application was unable to start correctly (0xc0000142).
    Click OK to close the application

The same happens with GDB 14.1, so this is not new.

According to this page:

https://github.com/msys2/MINGW-packages/issues/1744#issuecomment-256146266

the problem is with the newly-redesigned Windows Console in Windows 10
and 11, and the solution is either (a) use "set new-console 1" (to
direct the output of the debuggee to a separate console), or (b) turn
on the "Use legacy console" option of the Windows terminal.

I've successfully used "set new-console 1" (and would assume the
other solution also works, although I haven't tried), but are there
other, more convenient solutions for this?  Perhaps some change in
ncurses or in how GDB handles the debuggee output in this case?

Hannes, do you know anything about this?

Thanks.

Re: Building GDB 15.0.91 on MinGW: Problem with TUI

[Eli Zaretskii]

> Date: Fri, 7 Jun 2024 13:21:45 +0000 (UTC)
> From: Hannes Domani <ssbssa@yahoo.de>
> Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> 
> Isn't that the same as this issue?:
> https://github.com/msys2/MINGW-packages/issues/10434
> 
> If yes, it should be fixed with ncurses-6.4-20230211 or newer.

Right, thanks.  I need to upgrade my ncurses, I guess.