Building today's snapshot of GDB with MinGW

Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

At Joel's request I've built today's (29 June) snapshot of GDB using
mingw.org's MinGW and GCC 9.2.0.  There are a few issues I bumped into
related to Gnulib and MinGW runtime (which I recently upgraded to a
newer version), and I'm still working on those.  So what's below is an
interim report of issues related to GDB itself:

1. The configure script doesn't allow --with-static-standard-libraries
when GDB is built with source-highlight.  Is this limitation going to
stay (and if so, why), or could it be lifted?  (I needed to hack the
configure script to get past the error message.)

2. Building in libctf produces the same errors I reported back in
February for GDB 9.1.  I thought the libctf developer fixed them
up-stream (or was I dreaming?), so why isn't the fix in our
repository?  I fixed those exactly as I fixed them for GDB 9.1.

3. "make TAGS" in the gdb/ directory fails because HFILES_NO_SRCDIR
includes files that no longer exist: gdb_select.h and
tui/tui-windata.h.  Once these are removed from the list, TAGS is
built.

4. Running "maint selftests" produces several warnings and failures:

  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x86-64 settings.
  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x64-32 settings.
  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i8086 settings.
  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x86-64:intel settings.
  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x64-32:intel settings.
  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x86-64:nacl settings.
  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x64-32:nacl settings.
  Self test failed: self-test failed at unittests/format_pieces-selftests.c:37
  Self test failed: self-test failed at utils.c:2971
  Self test failed: arch i386:x86-64: Cannot access memory at address 0x0
  Self test failed: arch i386:x64-32: Cannot access memory at address 0x0
  Self test failed: arch i386:x86-64:intel: Cannot access memory at address 0x0
  Self test failed: arch i386:x64-32:intel: Cannot access memory at address 0x0
  Self test failed: arch i386:x86-64:nacl: Cannot access memory at address 0x0
  Self test failed: arch i386:x64-32:nacl: Cannot access memory at address 0x0
  Self test failed: self-test failed at selftest-arch.c:85
  warning: Could not recognize version of Intel Compiler in: "Intel(R) foo bar"
  Self test failed: Could not convert character to `UTF-8' character set
  Self test failed: self-test failed at unittests/scoped_fd-selftests.c:80

Is this something I should investigate?  (I have never before run
selftests in the MinGW build, so I have no "prior art" to compare
with.)

That's all for now.  HTH.

Re: Building today's snapshot of GDB with MinGW

[Christian Biesinger]

On Mon, Jun 29, 2020 at 1:27 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> At Joel's request I've built today's (29 June) snapshot of GDB using
> mingw.org's MinGW and GCC 9.2.0.  There are a few issues I bumped into
> related to Gnulib and MinGW runtime (which I recently upgraded to a
> newer version), and I'm still working on those.  So what's below is an
> interim report of issues related to GDB itself:
>
> 1. The configure script doesn't allow --with-static-standard-libraries
> when GDB is built with source-highlight.  Is this limitation going to
> stay (and if so, why), or could it be lifted?  (I needed to hack the
> configure script to get past the error message.)

Looks like this was discussed before at
https://sourceware.org/pipermail/gdb-patches/2020-April/167388.html,
no real outcome AFAICT

> 2. Building in libctf produces the same errors I reported back in
> February for GDB 9.1.  I thought the libctf developer fixed them
> up-stream (or was I dreaming?), so why isn't the fix in our
> repository?  I fixed those exactly as I fixed them for GDB 9.1.

So reading https://sourceware.org/bugzilla/show_bug.cgi?id=25155, Nick
mentioned an RFC patch, but I can't tell if that landed.

> 3. "make TAGS" in the gdb/ directory fails because HFILES_NO_SRCDIR
> includes files that no longer exist: gdb_select.h and
> tui/tui-windata.h.  Once these are removed from the list, TAGS is
> built.

This also happens on Linux. I guess few people use "make TAGS"...

> 4. Running "maint selftests" produces several warnings and failures:
>
>   warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x86-64 settings.

Possibly related to
https://sourceware.org/pipermail/gdb-patches/2020-March/166678.html ?


Christian

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Mon, 29 Jun 2020 15:36:50 -0500
> Cc: gdb-patches <gdb-patches@sourceware.org>
> 
> > 1. The configure script doesn't allow --with-static-standard-libraries
> > when GDB is built with source-highlight.  Is this limitation going to
> > stay (and if so, why), or could it be lifted?  (I needed to hack the
> > configure script to get past the error message.)
> 
> Looks like this was discussed before at
> https://sourceware.org/pipermail/gdb-patches/2020-April/167388.html,
> no real outcome AFAICT

Tom, could you please share your views on this?  You seemed to be
saying there that we must link libstdc++ dynamically to support
exceptions thrown by source-highlight, but could you perhaps add more
details about the reasons?  Also, do the problems you had in mind
affect GDB that is linked statically with source-highlight, and if
not, could we modify the configure script to allow that with
"-static-libstdc++"?

> > 2. Building in libctf produces the same errors I reported back in
> > February for GDB 9.1.  I thought the libctf developer fixed them
> > up-stream (or was I dreaming?), so why isn't the fix in our
> > repository?  I fixed those exactly as I fixed them for GDB 9.1.
> 
> So reading https://sourceware.org/bugzilla/show_bug.cgi?id=25155, Nick
> mentioned an RFC patch, but I can't tell if that landed.

Joel, should I install the same libctf patches we had in
gdb-9.1-branch in the current master?  Or would you like to talk to
the upstream maintainer first?

> > 3. "make TAGS" in the gdb/ directory fails because HFILES_NO_SRCDIR
> > includes files that no longer exist: gdb_select.h and
> > tui/tui-windata.h.  Once these are removed from the list, TAGS is
> > built.
> 
> This also happens on Linux. I guess few people use "make TAGS"...

Any reason not to delete those 2 file names from the list?

> > 4. Running "maint selftests" produces several warnings and failures:
> >
> >   warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x86-64 settings.
> 
> Possibly related to
> https://sourceware.org/pipermail/gdb-patches/2020-March/166678.html ?

Simon, any chance you could look into this, or instruct me how to
investigate?

Re: Building today's snapshot of GDB with MinGW

[Simon Marchi]

On 2020-06-30 10:09 a.m., Eli Zaretskii wrote:
>>> 4. Running "maint selftests" produces several warnings and failures:
>>>
>>>   warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x86-64 settings.
>>
>> Possibly related to
>> https://sourceware.org/pipermail/gdb-patches/2020-March/166678.html ?
> 
> Simon, any chance you could look into this, or instruct me how to
> investigate?

I built a GDB on Linux with a MinGW target and ran the self tests.  I got:

  warning: A handler for the OS ABI "Windows" is not built into this configuration
  of GDB.  Attempting to continue with the default i386:x64-32 settings.

  warning: A handler for the OS ABI "Windows" is not built into this configuration
  of GDB.  Attempting to continue with the default i8086 settings.

  warning: A handler for the OS ABI "Windows" is not built into this configuration
  of GDB.  Attempting to continue with the default i386:x64-32:intel settings.

These are pretty much expected.  For the "gdbarch selftests", we run some test using
all the arches known to BFD.  When initializing the gdbarch for these architectures,
the default osabi for that version of GDB is assumed (in gdbarch_info_fill).  In your
GDB or the GDB I compiled, the default osabi is Windows.

When trying to initialize that gdbarch, GDB just complains that it doesn't have support
for debugging Windows programs running on i386:x64-32, i386:x64-32:intel and i8086.  This
is expected, as i386:x64-32 is an ABI not supported by Windows.  And I presume i8086 is
the very old Intel architecture, which obviously does not support Windows.

However, some of the warnings you get are not expected:

  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x86-64 settings.
  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x64-32 settings.
  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i8086 settings.
  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x86-64:intel settings.
  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x64-32:intel settings.
  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x86-64:nacl settings.
  warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x64-32:nacl settings.

We would not expect GDB to complain for Windows on i386:x86-64.

The first thing I would do is make sure that the function _initialize_amd64_windows_tdep
gets executed at startup in your GDB.  This is the function that registers a handler for
the tuple (i386:x86-64, Windows).

Simon

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> Cc: gdb-patches@sourceware.org
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Date: Tue, 30 Jun 2020 18:24:11 -0400
> 
> However, some of the warnings you get are not expected:
> 
>   warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x86-64 settings.
>   warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x64-32 settings.
>   warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i8086 settings.
>   warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x86-64:intel settings.
>   warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x64-32:intel settings.
>   warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x86-64:nacl settings.
>   warning: A handler for the OS ABI "Windows" is not built into this configuration of GDB.  Attempting to continue with the default i386:x64-32:nacl settings.
> 
> We would not expect GDB to complain for Windows on i386:x86-64.
> 
> The first thing I would do is make sure that the function _initialize_amd64_windows_tdep
> gets executed at startup in your GDB.  This is the function that registers a handler for
> the tuple (i386:x86-64, Windows).

Thanks, I will take a look there and report what I see.

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> Date: Wed, 01 Jul 2020 18:09:11 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org, brobecker@adacore.com, tromey@adacore.com
> 
> > We would not expect GDB to complain for Windows on i386:x86-64.
> > 
> > The first thing I would do is make sure that the function _initialize_amd64_windows_tdep
> > gets executed at startup in your GDB.  This is the function that registers a handler for
> > the tuple (i386:x86-64, Windows).
> 
> Thanks, I will take a look there and report what I see.

I started looking at the code, but then I had a eureka moment.  You
mentioned _initialize_amd64_windows_tdep, so I presume you assumed my
build is a 64-bit one?  It isn't: it's a 3--bit build, and thus
_initialize_amd64_windows_tdep is not even compiled into the binary.

Given that my build is a 32-bit one, it sounds expected to see
warnings I cited, as they all complain about 64-bit architectures,
right?

Incidentally, I wonder why the gdbarch selftest is trying
architectures that are not supported and not even compiled in.  What
is the purpose of doing that?

Thanks.

Re: Building today's snapshot of GDB with MinGW

[Simon Marchi]

On 2020-07-02 9:50 a.m., Eli Zaretskii wrote:
>> Date: Wed, 01 Jul 2020 18:09:11 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: gdb-patches@sourceware.org, brobecker@adacore.com, tromey@adacore.com
>>
>>> We would not expect GDB to complain for Windows on i386:x86-64.
>>>
>>> The first thing I would do is make sure that the function _initialize_amd64_windows_tdep
>>> gets executed at startup in your GDB.  This is the function that registers a handler for
>>> the tuple (i386:x86-64, Windows).
>>
>> Thanks, I will take a look there and report what I see.
> 
> I started looking at the code, but then I had a eureka moment.  You
> mentioned _initialize_amd64_windows_tdep, so I presume you assumed my
> build is a 64-bit one?  It isn't: it's a 3--bit build, and thus
> _initialize_amd64_windows_tdep is not even compiled into the binary.
> 
> Given that my build is a 32-bit one, it sounds expected to see
> warnings I cited, as they all complain about 64-bit architectures,
> right?
> 
> Incidentally, I wonder why the gdbarch selftest is trying
> architectures that are not supported and not even compiled in.  What
> is the purpose of doing that?

It loops over all the architectures known to bfd.  So I suppose that in BFD,
enabling support for i386 enables support for x86-64, that it all comes
together.  But in GDB, when configuring GDB for a Windows i386 target, we
don't add support for Windows x86-64 targets.  So the warnings you see make
sense.

I noticed that when configuring GDB for an i386/Linux target, we also throw
in support for amd64/Linux as well if $enable_64_bit_bfd is true (which allows
a 32-bit program to read a large > 4GB executable, I suppose):

290 i[34567]86-*-linux*)
291         # Target: Intel 386 running GNU/Linux
292         gdb_target_obs="i386-linux-tdep.o \
293                         glibc-tdep.o \
294                         solib-svr4.o symfile-mem.o \
295                         linux-tdep.o linux-record.o"
296         if test "x$enable_64_bit_bfd" = "xyes"; then
297             # Target: GNU/Linux x86-64
298             gdb_target_obs="amd64-linux-tdep.o ${gdb_target_obs}"
299         fi
300         ;;

We could perhaps do the same for Windows, I don't think there would be any
downsides to it, and it could be useful to some people.

Simon

Re: Building today's snapshot of GDB with MinGW

[Simon Marchi]

On 2020-07-02 10:25 a.m., Simon Marchi wrote:
> On 2020-07-02 9:50 a.m., Eli Zaretskii wrote:
>>> Date: Wed, 01 Jul 2020 18:09:11 +0300
>>> From: Eli Zaretskii <eliz@gnu.org>
>>> Cc: gdb-patches@sourceware.org, brobecker@adacore.com, tromey@adacore.com
>>>
>>>> We would not expect GDB to complain for Windows on i386:x86-64.
>>>>
>>>> The first thing I would do is make sure that the function _initialize_amd64_windows_tdep
>>>> gets executed at startup in your GDB.  This is the function that registers a handler for
>>>> the tuple (i386:x86-64, Windows).
>>>
>>> Thanks, I will take a look there and report what I see.
>>
>> I started looking at the code, but then I had a eureka moment.  You
>> mentioned _initialize_amd64_windows_tdep, so I presume you assumed my
>> build is a 64-bit one?  It isn't: it's a 3--bit build, and thus
>> _initialize_amd64_windows_tdep is not even compiled into the binary.
>>
>> Given that my build is a 32-bit one, it sounds expected to see
>> warnings I cited, as they all complain about 64-bit architectures,
>> right?
>>
>> Incidentally, I wonder why the gdbarch selftest is trying
>> architectures that are not supported and not even compiled in.  What
>> is the purpose of doing that?
> 
> It loops over all the architectures known to bfd.  So I suppose that in BFD,
> enabling support for i386 enables support for x86-64, that it all comes
> together.  But in GDB, when configuring GDB for a Windows i386 target, we
> don't add support for Windows x86-64 targets.  So the warnings you see make
> sense.
> 
> I noticed that when configuring GDB for an i386/Linux target, we also throw
> in support for amd64/Linux as well if $enable_64_bit_bfd is true (which allows
> a 32-bit program to read a large > 4GB executable, I suppose):
> 
> 290 i[34567]86-*-linux*)
> 291         # Target: Intel 386 running GNU/Linux
> 292         gdb_target_obs="i386-linux-tdep.o \
> 293                         glibc-tdep.o \
> 294                         solib-svr4.o symfile-mem.o \
> 295                         linux-tdep.o linux-record.o"
> 296         if test "x$enable_64_bit_bfd" = "xyes"; then
> 297             # Target: GNU/Linux x86-64
> 298             gdb_target_obs="amd64-linux-tdep.o ${gdb_target_obs}"
> 299         fi
> 300         ;;
> 
> We could perhaps do the same for Windows, I don't think there would be any
> downsides to it, and it could be useful to some people.

In fact, we should probably do it, otherwise it's confusing.  You build GDB
for Windows, GDB claims that it supports x86-64, since you can set it using
"set architecture":

  (gdb) set architecture
  auto               i386               i386:intel         i386:x64-32        i386:x64-32:intel  i386:x86-64        i386:x86-64:intel  i8086

But that's not really helpful because that GDB doesn't know about Windows
on x86-64:

  (gdb) set architecture i386:x86-64
  warning: A handler for the OS ABI "Windows" is not built into this configuration
  of GDB.  Attempting to continue with the default i386:x86-64 settings.

  The target architecture is assumed to be i386:x86-64

Simon

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: gdb-patches@sourceware.org, brobecker@adacore.com, tromey@adacore.com
> Date: Thu, 2 Jul 2020 10:30:00 -0400
> 
> > 290 i[34567]86-*-linux*)
> > 291         # Target: Intel 386 running GNU/Linux
> > 292         gdb_target_obs="i386-linux-tdep.o \
> > 293                         glibc-tdep.o \
> > 294                         solib-svr4.o symfile-mem.o \
> > 295                         linux-tdep.o linux-record.o"
> > 296         if test "x$enable_64_bit_bfd" = "xyes"; then
> > 297             # Target: GNU/Linux x86-64
> > 298             gdb_target_obs="amd64-linux-tdep.o ${gdb_target_obs}"
> > 299         fi
> > 300         ;;
> > 
> > We could perhaps do the same for Windows, I don't think there would be any
> > downsides to it, and it could be useful to some people.
> 
> In fact, we should probably do it, otherwise it's confusing.  You build GDB
> for Windows, GDB claims that it supports x86-64, since you can set it using
> "set architecture":
> 
>   (gdb) set architecture
>   auto               i386               i386:intel         i386:x64-32        i386:x64-32:intel  i386:x86-64        i386:x86-64:intel  i8086
> 
> But that's not really helpful because that GDB doesn't know about Windows
> on x86-64:
> 
>   (gdb) set architecture i386:x86-64
>   warning: A handler for the OS ABI "Windows" is not built into this configuration
>   of GDB.  Attempting to continue with the default i386:x86-64 settings.
> 
>   The target architecture is assumed to be i386:x86-64

I agree.

Re: Building today's snapshot of GDB with MinGW

[Pedro Alves]

On 7/2/20 3:25 PM, Simon Marchi via Gdb-patches wrote:
> On 2020-07-02 9:50 a.m., Eli Zaretskii wrote:
>>> Date: Wed, 01 Jul 2020 18:09:11 +0300
>>> From: Eli Zaretskii <eliz@gnu.org>
>>> Cc: gdb-patches@sourceware.org, brobecker@adacore.com, tromey@adacore.com
>>>
>>>> We would not expect GDB to complain for Windows on i386:x86-64.
>>>>
>>>> The first thing I would do is make sure that the function _initialize_amd64_windows_tdep
>>>> gets executed at startup in your GDB.  This is the function that registers a handler for
>>>> the tuple (i386:x86-64, Windows).
>>>
>>> Thanks, I will take a look there and report what I see.
>>
>> I started looking at the code, but then I had a eureka moment.  You
>> mentioned _initialize_amd64_windows_tdep, so I presume you assumed my
>> build is a 64-bit one?  It isn't: it's a 3--bit build, and thus
>> _initialize_amd64_windows_tdep is not even compiled into the binary.
>>
>> Given that my build is a 32-bit one, it sounds expected to see
>> warnings I cited, as they all complain about 64-bit architectures,
>> right?
>>
>> Incidentally, I wonder why the gdbarch selftest is trying
>> architectures that are not supported and not even compiled in.  What
>> is the purpose of doing that?
> 
> It loops over all the architectures known to bfd.  So I suppose that in BFD,
> enabling support for i386 enables support for x86-64, that it all comes
> together.  But in GDB, when configuring GDB for a Windows i386 target, we
> don't add support for Windows x86-64 targets.  So the warnings you see make
> sense.
> 
> I noticed that when configuring GDB for an i386/Linux target, we also throw
> in support for amd64/Linux as well if $enable_64_bit_bfd is true (which allows
> a 32-bit program to read a large > 4GB executable, I suppose):
> 
> 290 i[34567]86-*-linux*)
> 291         # Target: Intel 386 running GNU/Linux
> 292         gdb_target_obs="i386-linux-tdep.o \
> 293                         glibc-tdep.o \
> 294                         solib-svr4.o symfile-mem.o \
> 295                         linux-tdep.o linux-record.o"
> 296         if test "x$enable_64_bit_bfd" = "xyes"; then
> 297             # Target: GNU/Linux x86-64
> 298             gdb_target_obs="amd64-linux-tdep.o ${gdb_target_obs}"
> 299         fi
> 300         ;;
> 

This is so a i686-linux-gnu hosted toolchain works with 64-bit binaries.
There are vendors who prefer (or used to prefer, time has passed
and don't know if that's still a thing) it that way, as it's a single
build for 32-bit and 64-bit hosts that way.   Users can then build
64-bit apps with e.g., "i686-unknown-linux-gnu-gcc -m64".  Naturally,
the debugger follows suit (though that's only useful for cross debugging,
since for native debugging 64-bit inferiors, you need a 64-bit debugger).

See:

https://sourceware.org/legacy-ml/gdb-patches/2009-04/msg00420.html

> We could perhaps do the same for Windows, I don't think there would be any
> downsides to it, and it could be useful to some people.
> 

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> Cc: tromey@adacore.com, brobecker@adacore.com, gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> Date: Thu, 2 Jul 2020 15:40:20 +0100
> 
> > 290 i[34567]86-*-linux*)
> > 291         # Target: Intel 386 running GNU/Linux
> > 292         gdb_target_obs="i386-linux-tdep.o \
> > 293                         glibc-tdep.o \
> > 294                         solib-svr4.o symfile-mem.o \
> > 295                         linux-tdep.o linux-record.o"
> > 296         if test "x$enable_64_bit_bfd" = "xyes"; then
> > 297             # Target: GNU/Linux x86-64
> > 298             gdb_target_obs="amd64-linux-tdep.o ${gdb_target_obs}"
> > 299         fi
> > 300         ;;
> > 
> 
> This is so a i686-linux-gnu hosted toolchain works with 64-bit binaries.
> There are vendors who prefer (or used to prefer, time has passed
> and don't know if that's still a thing) it that way, as it's a single
> build for 32-bit and 64-bit hosts that way.   Users can then build
> 64-bit apps with e.g., "i686-unknown-linux-gnu-gcc -m64".  Naturally,
> the debugger follows suit (though that's only useful for cross debugging,
> since for native debugging 64-bit inferiors, you need a 64-bit debugger).

Thanks.

AFAIK, this is impossible on Windows: a 64-bit debugger can debug
32-bit programs (and I think GDB recently learned how to do that), but
a 32-bit debugger cannot debug 64-bit programs.

Re: Building today's snapshot of GDB with MinGW

[Pedro Alves]

On 7/2/20 6:46 PM, Eli Zaretskii wrote:
>> Cc: tromey@adacore.com, brobecker@adacore.com, gdb-patches@sourceware.org
>> From: Pedro Alves <pedro@palves.net>
>> Date: Thu, 2 Jul 2020 15:40:20 +0100
>>
>>> 290 i[34567]86-*-linux*)
>>> 291         # Target: Intel 386 running GNU/Linux
>>> 292         gdb_target_obs="i386-linux-tdep.o \
>>> 293                         glibc-tdep.o \
>>> 294                         solib-svr4.o symfile-mem.o \
>>> 295                         linux-tdep.o linux-record.o"
>>> 296         if test "x$enable_64_bit_bfd" = "xyes"; then
>>> 297             # Target: GNU/Linux x86-64
>>> 298             gdb_target_obs="amd64-linux-tdep.o ${gdb_target_obs}"
>>> 299         fi
>>> 300         ;;
>>>
>>
>> This is so a i686-linux-gnu hosted toolchain works with 64-bit binaries.
>> There are vendors who prefer (or used to prefer, time has passed
>> and don't know if that's still a thing) it that way, as it's a single
>> build for 32-bit and 64-bit hosts that way.   Users can then build
>> 64-bit apps with e.g., "i686-unknown-linux-gnu-gcc -m64".  Naturally,
>> the debugger follows suit (though that's only useful for cross debugging,
>> since for native debugging 64-bit inferiors, you need a 64-bit debugger).
> 
> Thanks.
> 
> AFAIK, this is impossible on Windows: a 64-bit debugger can debug
> 32-bit programs (and I think GDB recently learned how to do that), but
> a 32-bit debugger cannot debug 64-bit programs.
> 

Which is exactly the same with Linux.  See my parenthetical remark above.

I.e., a 32-bit GNU/Linux gdb cannot debug a native 64-bit program, but
it can debug against a 64-bit GNU/Linux gdbserver.

So if you make a similar change for Windows, you'll make it so that
a 32-bit Windows gdb could debug against a 64-bit Windows gdbserver.
Whether that's really useful, I have no clue.  All depends on how you
intend to ship the binaries.  Maybe vendors have all switched to
64-bit-hosted toolchains nowadays.

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> Cc: simon.marchi@polymtl.ca, tromey@adacore.com, brobecker@adacore.com,
>  gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> Date: Thu, 2 Jul 2020 19:21:17 +0100
> 
> > AFAIK, this is impossible on Windows: a 64-bit debugger can debug
> > 32-bit programs (and I think GDB recently learned how to do that), but
> > a 32-bit debugger cannot debug 64-bit programs.
> > 
> 
> Which is exactly the same with Linux.  See my parenthetical remark above.

Right, I missed that, sorry.

Re: Building today's snapshot of GDB with MinGW

[Pedro Alves]

On 7/2/20 7:33 PM, Eli Zaretskii wrote:
>> Cc: simon.marchi@polymtl.ca, tromey@adacore.com, brobecker@adacore.com,
>>  gdb-patches@sourceware.org
>> From: Pedro Alves <pedro@palves.net>
>> Date: Thu, 2 Jul 2020 19:21:17 +0100
>>
>>> AFAIK, this is impossible on Windows: a 64-bit debugger can debug
>>> 32-bit programs (and I think GDB recently learned how to do that), but
>>> a 32-bit debugger cannot debug 64-bit programs.
>>>
>>
>> Which is exactly the same with Linux.  See my parenthetical remark above.
> 
> Right, I missed that, sorry.
> 

No worries at all.

Cheers,
Pedro Alves

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

I tried today "gdb --tui" on Windows 10, and was surprised to find
that it doesn't work: the debuggee fails to start when you type "run"
or "start".  Windows pops up a dialog saying

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

The application whose name is shown on the popup is the debuggee, but
the Windows Event Log shows a crash in the Windows console host.

This is not new, I see the same problem in all versions of GDB back to
7.9.  It could be related to running a 32-bit debugger on 64-bit
Windows OS, though.

The only discussion of this that seems relevant is here:

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

I tried the workaround mentioned there with "set new-console on", and
it didn't work.  The discussion further suggests to switch the Windows
console to the legacy mode, which I didn't try (because it affects all
console windows and requires restart AFAICT).  This URL is from 4
years ago, so maybe the current builds of Windows 10 are different;
the version I tried this on is build 18362.836.

Did anyone try running "gdb --tui" on Windows 10 console, and if so,
did that work for you?

Re: Building today's snapshot of GDB with MinGW

[Christian Biesinger]

On Wed, Jul 1, 2020 at 10:20 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> I tried today "gdb --tui" on Windows 10, and was surprised to find
> that it doesn't work: the debuggee fails to start when you type "run"
> or "start".  Windows pops up a dialog saying
>
>   The application was unable to start correctly (0xc0000142)
>   Click OK to close the application.

Odd... that's STATUS_DLL_INIT_FAILED...

I see the same thing, with mingw64. And after that, the cmd.exe window
seems to hang for some seconds and then the entire window closes
(crashes, presumably, but no crash dialog).

I don't have time right now to look into this any further, but I can
confirm you're not the only one.

Christian

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Wed, 1 Jul 2020 14:25:22 -0500
> Cc: Simon Marchi <simon.marchi@polymtl.ca>, Tom Tromey <tromey@adacore.com>, 
> 	Joel Brobecker <brobecker@adacore.com>, gdb-patches <gdb-patches@sourceware.org>
> 
> >   The application was unable to start correctly (0xc0000142)
> >   Click OK to close the application.
> 
> Odd... that's STATUS_DLL_INIT_FAILED...

Right.

> I see the same thing, with mingw64. And after that, the cmd.exe window
> seems to hang for some seconds and then the entire window closes
> (crashes, presumably, but no crash dialog).

No crash dialog, but you will see in the Windows Event Log that the
console host crashed.

> I don't have time right now to look into this any further, but I can
> confirm you're not the only one.

Thanks for verifying that.

Re: Building today's snapshot of GDB with MinGW

[Hannes Domani]

 Am Donnerstag, 2. Juli 2020, 04:30:01 MESZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:

> > From: Christian Biesinger <cbiesinger@google.com>
> > Date: Wed, 1 Jul 2020 14:25:22 -0500
> > Cc: Simon Marchi <simon.marchi@polymtl.ca>, Tom Tromey <tromey@adacore.com>,
> >     Joel Brobecker <brobecker@adacore.com>, gdb-patches <gdb-patches@sourceware.org>
> >
> > >  The application was unable to start correctly (0xc0000142)
> > >  Click OK to close the application.
> >
> > Odd... that's STATUS_DLL_INIT_FAILED...
>
> Right.
>
> > I see the same thing, with mingw64. And after that, the cmd.exe window
> > seems to hang for some seconds and then the entire window closes
> > (crashes, presumably, but no crash dialog).
>
> No crash dialog, but you will see in the Windows Event Log that the
> console host crashed.
>
>
> > I don't have time right now to look into this any further, but I can
> > confirm you're not the only one.
>
>
> Thanks for verifying that.

I never had this kind of problem on Windows 10, probably because I use
pdcurses instead of ncurses.


Hannes

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> Date: Thu, 2 Jul 2020 10:18:20 +0000 (UTC)
> From: Hannes Domani <ssbssa@yahoo.de>
> Cc: gdb-patches@sourceware.org, brobecker@adacore.com, tromey@adacore.com
> 
> I never had this kind of problem on Windows 10, probably because I use
> pdcurses instead of ncurses.

Are your command prompt windows working in the native mode or in
legacy mode?

If this is specific to ncurses, maybe we should ask Thom Dickey to
investigate this.

Re: Building today's snapshot of GDB with MinGW

[Hannes Domani]

 Am Donnerstag, 2. Juli 2020, 15:20:50 MESZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:

> > Date: Thu, 2 Jul 2020 10:18:20 +0000 (UTC)
> > From: Hannes Domani <ssbssa@yahoo.de>
> > Cc: gdb-patches@sourceware.org, brobecker@adacore.com, tromey@adacore.com
>
> >
> > I never had this kind of problem on Windows 10, probably because I use
> > pdcurses instead of ncurses.
>
>
> Are your command prompt windows working in the native mode or in
> legacy mode?
>
> If this is specific to ncurses, maybe we should ask Thom Dickey to
> investigate this.

I actually didn't know about legacy/native mode until you mentioned it.
And I checked now, I'm using native mode.


Hannes

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> Date: Mon, 6 Jul 2020 10:39:28 +0000 (UTC)
> From: Hannes Domani <ssbssa@yahoo.de>
> Cc: cbiesinger@google.com, gdb-patches@sourceware.org, brobecker@adacore.com, 
> 	tromey@adacore.com
> 
> > > I never had this kind of problem on Windows 10, probably because I use
> > > pdcurses instead of ncurses.
> >
> >
> > Are your command prompt windows working in the native mode or in
> > legacy mode?
> >
> > If this is specific to ncurses, maybe we should ask Thom Dickey to
> > investigate this.
> 
> I actually didn't know about legacy/native mode until you mentioned it.
> And I checked now, I'm using native mode.

Thanks.

It is strange that one version of curses triggers the problem while
another doesn't.  I guess one needs to look at the low-level code used
by ncurses to access the Windows console device.

Re: Building today's snapshot of GDB with MinGW

[Joel Brobecker]

Hi Eli,

> > So reading https://sourceware.org/bugzilla/show_bug.cgi?id=25155, Nick
> > mentioned an RFC patch, but I can't tell if that landed.
> 
> Joel, should I install the same libctf patches we had in
> gdb-9.1-branch in the current master?  Or would you like to talk to
> the upstream maintainer first?

Would you mind reaching out to Nick and see what he says? From memory,
what he said was that he had a patch that did away with using errno
values, and that the only blocking point was setting up an environment
to be able to reproduce. I felt back then that this was admirable for
him to try to achieve that, but on the other hand, I was quite concerned
that he was setting the bar to high for himself, and that this would
eventually lead to this being dropped on the floor. That why I offered
"our" (I mean, "your" ;-)) help to validate his patch. Actually, even
if you didn't have the cycles to test it, I think that testing this
kind of patch on his usual architectures would have been sufficient.
So let's just ask him what he prefers, knowing that we need a solution
soon, and that we're happy with using the same hack as on the
gdb-9-branch if that reduces the pressure on his end.

I can join in the discussion if that helps as well.

-- 
Joel

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> Date: Wed, 1 Jul 2020 12:25:41 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Christian Biesinger <cbiesinger@google.com>,
> 	Tom Tromey <tromey@adacore.com>, simon.marchi@polymtl.ca,
> 	gdb-patches@sourceware.org
> 
> > Joel, should I install the same libctf patches we had in
> > gdb-9.1-branch in the current master?  Or would you like to talk to
> > the upstream maintainer first?
> 
> Would you mind reaching out to Nick and see what he says?

Done.

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> Date: Mon, 29 Jun 2020 21:27:32 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> At Joel's request I've built today's (29 June) snapshot of GDB using
> mingw.org's MinGW and GCC 9.2.0.  There are a few issues I bumped into
> related to Gnulib and MinGW runtime (which I recently upgraded to a
> newer version), and I'm still working on those.  So what's below is an
> interim report of issues related to GDB itself:

More information:

Two issues I reported to Gnulib were fixed:

  https://lists.gnu.org/archive/html/bug-gnulib/2020-06/msg00068.html
  https://lists.gnu.org/archive/html/bug-gnulib/2020-06/msg00069.html

So I hope we could update from Gnulib before the GDB 10 branch is cut.

Another problem is specific to the MinGW headers, and was also fixed:

  https://osdn.net/projects/mingw/lists/archive/users/2020-June/000543.html

Yet another problem, which I'm not yet sure whether it's specific to
MinGW or to Windows XP, is still unfolding:

  https://osdn.net/projects/mingw/lists/archive/users/2020-June/000541.html

It currently makes me unable to run the built GDB on Windows XP, but I
can run it on newer versions of Windows.  So this is not a blocking
problem.

Last, but not least: the test we do in gdbserver/configure for the
socklen_t data type declaration doesn't work on Windows.  We do this:

  AC_CHECK_TYPES(socklen_t, [], [],
  [#include <sys/types.h>
  #include <sys/socket.h>
  ])

But on Windows this fails, because sys/socket.h doesn't exist;
instead, socklen_t is supposed to be defined in ws2tcpip.h.  So the
correct headers inclusion for the test program would be

  #include <sys/types.h>
  #if HAVE_SYS_SOCKET_H
  # include <sys/socket.h>
  #elif HAVE_WS2TCPIP_H
  # include <ws2tcpip.h>

Can we please fix this minor issue?

Thanks.

Re: Building today's snapshot of GDB with MinGW

[Christian Biesinger]

On Tue, Jun 30, 2020 at 11:18 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Mon, 29 Jun 2020 21:27:32 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> >
> > At Joel's request I've built today's (29 June) snapshot of GDB using
> > mingw.org's MinGW and GCC 9.2.0.  There are a few issues I bumped into
> > related to Gnulib and MinGW runtime (which I recently upgraded to a
> > newer version), and I'm still working on those.  So what's below is an
> > interim report of issues related to GDB itself:
>
> More information:
>
> Two issues I reported to Gnulib were fixed:
>
>   https://lists.gnu.org/archive/html/bug-gnulib/2020-06/msg00068.html
>   https://lists.gnu.org/archive/html/bug-gnulib/2020-06/msg00069.html
>
> So I hope we could update from Gnulib before the GDB 10 branch is cut.

I can make a patch for that.

> Another problem is specific to the MinGW headers, and was also fixed:
>
>   https://osdn.net/projects/mingw/lists/archive/users/2020-June/000543.html

Better link, I think:
https://osdn.net/projects/mingw/lists/archive/users/2020-June/000548.html
"feel free to modify your local copy, and I'll revert that change for
future releases."

Christian

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Tue, 30 Jun 2020 13:21:44 -0500
> Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches <gdb-patches@sourceware.org>
> 
> > Two issues I reported to Gnulib were fixed:
> >
> >   https://lists.gnu.org/archive/html/bug-gnulib/2020-06/msg00068.html
> >   https://lists.gnu.org/archive/html/bug-gnulib/2020-06/msg00069.html
> >
> > So I hope we could update from Gnulib before the GDB 10 branch is cut.
> 
> I can make a patch for that.

Thank you.

> > Another problem is specific to the MinGW headers, and was also fixed:
> >
> >   https://osdn.net/projects/mingw/lists/archive/users/2020-June/000543.html
> 
> Better link, I think:
> https://osdn.net/projects/mingw/lists/archive/users/2020-June/000548.html
> "feel free to modify your local copy, and I'll revert that change for
> future releases."

Yes, in each case I pointed to the beginning of the respective thread,
not to the message with the resolution.

Re: Building today's snapshot of GDB with MinGW

[Joel Brobecker]

Hi Eli,

> Yet another problem, which I'm not yet sure whether it's specific to
> MinGW or to Windows XP, is still unfolding:
> 
>   https://osdn.net/projects/mingw/lists/archive/users/2020-June/000541.html
> 
> It currently makes me unable to run the built GDB on Windows XP, but I
> can run it on newer versions of Windows.  So this is not a blocking
> problem.

I thought we dropped support for Windows XP? I think that is
a reasonable assumption, considering how long ago MS dropped
support for that version.

-- 
Joel

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> Date: Wed, 1 Jul 2020 12:29:13 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> >   https://osdn.net/projects/mingw/lists/archive/users/2020-June/000541.html
> > 
> > It currently makes me unable to run the built GDB on Windows XP, but I
> > can run it on newer versions of Windows.  So this is not a blocking
> > problem.
> 
> I thought we dropped support for Windows XP? I think that is
> a reasonable assumption, considering how long ago MS dropped
> support for that version.

Which is why I said this should not block the branching.  (My main
Windows development machine runs Windows XP, so it's important to me,
but that's me.)

P.S. I don't think GDB dropped support for XP, it's MinGW64 that did.

Re: Building today's snapshot of GDB with MinGW

[Joel Brobecker]

> Last, but not least: the test we do in gdbserver/configure for the
> socklen_t data type declaration doesn't work on Windows.  We do this:
> 
>   AC_CHECK_TYPES(socklen_t, [], [],
>   [#include <sys/types.h>
>   #include <sys/socket.h>
>   ])
> 
> But on Windows this fails, because sys/socket.h doesn't exist;
> instead, socklen_t is supposed to be defined in ws2tcpip.h.  So the
> correct headers inclusion for the test program would be
> 
>   #include <sys/types.h>
>   #if HAVE_SYS_SOCKET_H
>   # include <sys/socket.h>
>   #elif HAVE_WS2TCPIP_H
>   # include <ws2tcpip.h>
> 
> Can we please fix this minor issue?

Would you be able to submit a patch?

-- 
Joel

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> Date: Wed, 1 Jul 2020 12:30:26 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> >   AC_CHECK_TYPES(socklen_t, [], [],
> >   [#include <sys/types.h>
> >   #include <sys/socket.h>
> >   ])
> > 
> > But on Windows this fails, because sys/socket.h doesn't exist;
> > instead, socklen_t is supposed to be defined in ws2tcpip.h.  So the
> > correct headers inclusion for the test program would be
> > 
> >   #include <sys/types.h>
> >   #if HAVE_SYS_SOCKET_H
> >   # include <sys/socket.h>
> >   #elif HAVE_WS2TCPIP_H
> >   # include <ws2tcpip.h>
> > 
> > Can we please fix this minor issue?
> 
> Would you be able to submit a patch?

I can submit a change, but it would be difficult for me to try it, and
regenerate configure in general (I don't have the right version of
Autotools installed).  Would it be okay to send a change and ask
someone to do the rest?

Re: Building today's snapshot of GDB with MinGW

[Joel Brobecker]

> I can submit a change, but it would be difficult for me to try it, and
> regenerate configure in general (I don't have the right version of
> Autotools installed).  Would it be okay to send a change and ask
> someone to do the rest?

No problem; if you send me the configure.xxx change, I can re-run
autoconf et al, and send you a diff with the regenerated files.
We can do that as a private exchange to avoid bothering everyone
else for that part.

-- 
Joel

Re: Building today's snapshot of GDB with MinGW

[Tom de Vries]

On 7/3/20 5:25 PM, Joel Brobecker wrote:
>> I can submit a change, but it would be difficult for me to try it, and
>> regenerate configure in general (I don't have the right version of
>> Autotools installed).  Would it be okay to send a change and ask
>> someone to do the rest?
> 
> No problem; if you send me the configure.xxx change, I can re-run
> autoconf et al, and send you a diff with the regenerated files.
> We can do that as a private exchange to avoid bothering everyone
> else for that part.
> 

Hi,

[ I suppose this is the last message related to commit 05a6b8c28b "Don't
unnecessarily redefine 'socklen_t' type in MinGW builds.". ]

I ran into a build breaker related to this commit:
...
src/gdb/ser-tcp.c:65:13: error: conflicting declaration ‘typedef int
socklen_t’
   65 | typedef int socklen_t;
      |             ^~~~~~~~~
In file included from ../gnulib/import/unistd.h:40,
                 from
/home/vries/gdb_versions/devel/src/gdb/../gnulib/import/pathmax.h:42,
                 from
/home/vries/gdb_versions/devel/src/gdb/../gdbsupport/common-defs.h:120,
                 from /home/vries/gdb_versions/devel/src/gdb/defs.h:28,
                 from /home/vries/gdb_versions/devel/src/gdb/ser-tcp.c:20:
/usr/include/unistd.h:277:21: note: previous declaration as ‘typedef
__socklen_t socklen_t’
  277 | typedef __socklen_t socklen_t;
      |                     ^~~~~~~~~
...

Thanks,
- Tom

Re: Building today's snapshot of GDB with MinGW

[Tom de Vries]

On 7/27/20 11:49 AM, Tom de Vries wrote:
> On 7/3/20 5:25 PM, Joel Brobecker wrote:
>>> I can submit a change, but it would be difficult for me to try it, and
>>> regenerate configure in general (I don't have the right version of
>>> Autotools installed).  Would it be okay to send a change and ask
>>> someone to do the rest?
>>
>> No problem; if you send me the configure.xxx change, I can re-run
>> autoconf et al, and send you a diff with the regenerated files.
>> We can do that as a private exchange to avoid bothering everyone
>> else for that part.
>>
> 
> Hi,
> 
> [ I suppose this is the last message related to commit 05a6b8c28b "Don't
> unnecessarily redefine 'socklen_t' type in MinGW builds.". ]
> 
> I ran into a build breaker related to this commit:
> ...
> src/gdb/ser-tcp.c:65:13: error: conflicting declaration ‘typedef int
> socklen_t’
>    65 | typedef int socklen_t;
>       |             ^~~~~~~~~
> In file included from ../gnulib/import/unistd.h:40,
>                  from
> /home/vries/gdb_versions/devel/src/gdb/../gnulib/import/pathmax.h:42,
>                  from
> /home/vries/gdb_versions/devel/src/gdb/../gdbsupport/common-defs.h:120,
>                  from /home/vries/gdb_versions/devel/src/gdb/defs.h:28,
>                  from /home/vries/gdb_versions/devel/src/gdb/ser-tcp.c:20:
> /usr/include/unistd.h:277:21: note: previous declaration as ‘typedef
> __socklen_t socklen_t’
>   277 | typedef __socklen_t socklen_t;
>       |                     ^~~~~~~~~
> ...
> 

Hmm, this looks fishy:
...
/* Define to 1 if you have the <sys/sockets.h> header file. */

#undef HAVE_SYS_SOCKETS_H



/* Define to 1 if you have the <sys/socket.h> header file. */

#undef HAVE_SYS_SOCKET_H
                      ...

Anyway, in configure.ac, the check for HAVE_SYS_SOCKET_H comes before
the check for HAVE_SOCKLEN_T, but in configure, that order is reversed,
which is the root cause for the breakage.

It looks like AC_CHECK_HEADERS accumulated checks for different header
files, and that that caused the order reversal.

Thanks,
- Tom

Re: Building today's snapshot of GDB with MinGW

[Tom de Vries]

On 7/27/20 12:05 PM, Tom de Vries wrote:
> On 7/27/20 11:49 AM, Tom de Vries wrote:
>> On 7/3/20 5:25 PM, Joel Brobecker wrote:
>>>> I can submit a change, but it would be difficult for me to try it, and
>>>> regenerate configure in general (I don't have the right version of
>>>> Autotools installed).  Would it be okay to send a change and ask
>>>> someone to do the rest?
>>>
>>> No problem; if you send me the configure.xxx change, I can re-run
>>> autoconf et al, and send you a diff with the regenerated files.
>>> We can do that as a private exchange to avoid bothering everyone
>>> else for that part.
>>>
>>
>> Hi,
>>
>> [ I suppose this is the last message related to commit 05a6b8c28b "Don't
>> unnecessarily redefine 'socklen_t' type in MinGW builds.". ]
>>
>> I ran into a build breaker related to this commit:
>> ...
>> src/gdb/ser-tcp.c:65:13: error: conflicting declaration ‘typedef int
>> socklen_t’
>>    65 | typedef int socklen_t;
>>       |             ^~~~~~~~~
>> In file included from ../gnulib/import/unistd.h:40,
>>                  from
>> /home/vries/gdb_versions/devel/src/gdb/../gnulib/import/pathmax.h:42,
>>                  from
>> /home/vries/gdb_versions/devel/src/gdb/../gdbsupport/common-defs.h:120,
>>                  from /home/vries/gdb_versions/devel/src/gdb/defs.h:28,
>>                  from /home/vries/gdb_versions/devel/src/gdb/ser-tcp.c:20:
>> /usr/include/unistd.h:277:21: note: previous declaration as ‘typedef
>> __socklen_t socklen_t’
>>   277 | typedef __socklen_t socklen_t;
>>       |                     ^~~~~~~~~
>> ...
>>
> 
> Hmm, this looks fishy:
> ...
> /* Define to 1 if you have the <sys/sockets.h> header file. */
> 
> #undef HAVE_SYS_SOCKETS_H
> 
> 
> 
> /* Define to 1 if you have the <sys/socket.h> header file. */
> 
> #undef HAVE_SYS_SOCKET_H
>                       ...
> 
> Anyway, in configure.ac, the check for HAVE_SYS_SOCKET_H comes before
> the check for HAVE_SOCKLEN_T, but in configure, that order is reversed,
> which is the root cause for the breakage.
> 
> It looks like AC_CHECK_HEADERS accumulated checks for different header
> files, and that that caused the order reversal.
> 

Scrap that.

It's a typo : sys/sockets.h instead of sys/socket.h.

Thanks,
- Tom

[committed][gdb/build] Fix typo sys/sockets.h -> sys/socket.h

[Tom de Vries]

[-- Attachment #1: Type: text/plain, Size: 2446 bytes --]

[ was: Re: Building today's snapshot of GDB with MinGW ]

On 7/27/20 12:26 PM, Tom de Vries wrote:
> On 7/27/20 12:05 PM, Tom de Vries wrote:
>> On 7/27/20 11:49 AM, Tom de Vries wrote:
>>> On 7/3/20 5:25 PM, Joel Brobecker wrote:
>>>>> I can submit a change, but it would be difficult for me to try it, and
>>>>> regenerate configure in general (I don't have the right version of
>>>>> Autotools installed).  Would it be okay to send a change and ask
>>>>> someone to do the rest?
>>>>
>>>> No problem; if you send me the configure.xxx change, I can re-run
>>>> autoconf et al, and send you a diff with the regenerated files.
>>>> We can do that as a private exchange to avoid bothering everyone
>>>> else for that part.
>>>>
>>>
>>> Hi,
>>>
>>> [ I suppose this is the last message related to commit 05a6b8c28b "Don't
>>> unnecessarily redefine 'socklen_t' type in MinGW builds.". ]
>>>
>>> I ran into a build breaker related to this commit:
>>> ...
>>> src/gdb/ser-tcp.c:65:13: error: conflicting declaration ‘typedef int
>>> socklen_t’
>>>    65 | typedef int socklen_t;
>>>       |             ^~~~~~~~~
>>> In file included from ../gnulib/import/unistd.h:40,
>>>                  from
>>> /home/vries/gdb_versions/devel/src/gdb/../gnulib/import/pathmax.h:42,
>>>                  from
>>> /home/vries/gdb_versions/devel/src/gdb/../gdbsupport/common-defs.h:120,
>>>                  from /home/vries/gdb_versions/devel/src/gdb/defs.h:28,
>>>                  from /home/vries/gdb_versions/devel/src/gdb/ser-tcp.c:20:
>>> /usr/include/unistd.h:277:21: note: previous declaration as ‘typedef
>>> __socklen_t socklen_t’
>>>   277 | typedef __socklen_t socklen_t;
>>>       |                     ^~~~~~~~~
>>> ...
>>>
>>
>> Hmm, this looks fishy:
>> ...
>> /* Define to 1 if you have the <sys/sockets.h> header file. */
>>
>> #undef HAVE_SYS_SOCKETS_H
>>
>>
>>
>> /* Define to 1 if you have the <sys/socket.h> header file. */
>>
>> #undef HAVE_SYS_SOCKET_H
>>                       ...
>>
>> Anyway, in configure.ac, the check for HAVE_SYS_SOCKET_H comes before
>> the check for HAVE_SOCKLEN_T, but in configure, that order is reversed,
>> which is the root cause for the breakage.
>>
>> It looks like AC_CHECK_HEADERS accumulated checks for different header
>> files, and that that caused the order reversal.
>>
> 
> Scrap that.
> 
> It's a typo : sys/sockets.h instead of sys/socket.h.

Fixed in patch below, committed.

Thanks,
- Tom

[-- Attachment #2: 0001-gdb-build-Fix-typo-sys-sockets.h-sys-socket.h.patch --]
[-- Type: text/x-patch, Size: 2727 bytes --]

[gdb/build] Fix typo sys/sockets.h -> sys/socket.h

I'm running into a build breaker:
...
src/gdb/ser-tcp.c:65:13: error: conflicting declaration ‘typedef int
socklen_t’
   65 | typedef int socklen_t;
      |             ^~~~~~~~~
In file included from ../gnulib/import/unistd.h:40,
                 from
/home/vries/gdb_versions/devel/src/gdb/../gnulib/import/pathmax.h:42,
                 from
/home/vries/gdb_versions/devel/src/gdb/../gdbsupport/common-defs.h:120,
                 from src/gdb/defs.h:28,
                 from src/gdb/ser-tcp.c:20:
/usr/include/unistd.h:277:21: note: previous declaration as ‘typedef
__socklen_t socklen_t’
  277 | typedef __socklen_t socklen_t;
      |                     ^~~~~~~~~
...
after commit 05a6b8c28b "Don't unnecessarily redefine 'socklen_t' type in
MinGW builds".

The root cause is a typo in gdb/configure.ac, using sys/sockets.h where
sys/socket.h was meant:
...
AC_CHECK_HEADERS([sys/sockets.h])
...

Fix the typo.

Build and tested on x86_64-linux.

gdb/ChangeLog:

2020-07-27  Tom de Vries  <tdevries@suse.de>

	* configure.ac: Fix sys/sockets.h -> sys/socket.h typo.
	* config.in: Regenerate.
	* configure: Regenerate.

---
 gdb/config.in    | 3 ---
 gdb/configure    | 8 ++++----
 gdb/configure.ac | 2 +-
 3 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/gdb/config.in b/gdb/config.in
index 26053475db..1aeb8603a1 100644
--- a/gdb/config.in
+++ b/gdb/config.in
@@ -505,9 +505,6 @@
 /* Define to 1 if you have the <sys/select.h> header file. */
 #undef HAVE_SYS_SELECT_H
 
-/* Define to 1 if you have the <sys/sockets.h> header file. */
-#undef HAVE_SYS_SOCKETS_H
-
 /* Define to 1 if you have the <sys/socket.h> header file. */
 #undef HAVE_SYS_SOCKET_H
 
diff --git a/gdb/configure b/gdb/configure
index c9a4b42ea1..adcfa49c63 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -11844,12 +11844,12 @@ fi
 done
 
 
-for ac_header in sys/sockets.h
+for ac_header in sys/socket.h
 do :
-  ac_fn_c_check_header_mongrel "$LINENO" "sys/sockets.h" "ac_cv_header_sys_sockets_h" "$ac_includes_default"
-if test "x$ac_cv_header_sys_sockets_h" = xyes; then :
+  ac_fn_c_check_header_mongrel "$LINENO" "sys/socket.h" "ac_cv_header_sys_socket_h" "$ac_includes_default"
+if test "x$ac_cv_header_sys_socket_h" = xyes; then :
   cat >>confdefs.h <<_ACEOF
-#define HAVE_SYS_SOCKETS_H 1
+#define HAVE_SYS_SOCKET_H 1
 _ACEOF
 
 fi
diff --git a/gdb/configure.ac b/gdb/configure.ac
index 3bec21560e..620ae23e34 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -1248,7 +1248,7 @@ AC_CHECK_HEADERS(term.h, [], [],
 #endif
 ])
 
-AC_CHECK_HEADERS([sys/sockets.h])
+AC_CHECK_HEADERS([sys/socket.h])
 AC_CHECK_HEADERS([ws2tcpip.h])
 
 # ------------------------- #

Re: [committed][gdb/build] Fix typo sys/sockets.h -> sys/socket.h

[Joel Brobecker]

> 2020-07-27  Tom de Vries  <tdevries@suse.de>
> 
> 	* configure.ac: Fix sys/sockets.h -> sys/socket.h typo.
> 	* config.in: Regenerate.
> 	* configure: Regenerate.

Thank you Tom.

-- 
Joel

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> From: Tom de Vries <tdevries@suse.de>
> Cc: gdb-patches@sourceware.org
> Date: Mon, 27 Jul 2020 12:26:24 +0200
> 
> It's a typo : sys/sockets.h instead of sys/socket.h.

Sorry about that, and thanks for fixing the typo.

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> Date: Mon, 29 Jun 2020 21:27:32 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> 4. Running "maint selftests" produces several warnings and failures:

I took a closer look at the selftest failures unrelated to
architectures.  There are a few:

>   Self test failed: self-test failed at unittests/format_pieces-selftests.c:37
>   Self test failed: self-test failed at utils.c:2971
>   Self test failed: Could not convert character to `UTF-8' character set
>   Self test failed: self-test failed at unittests/scoped_fd-selftests.c:80

The one in utils.c:2971 tests gdb_realpath.  It fails because
gdb_realpath implementation on MS-Windows returns a file name with
backslashes, whereas the test compares the basename of the value
starting with the last slash.  The patch to fix that is attached at
the end of this message.

The UTF-8 conversion problem comes from the Rust tests.  I don't
really understand why would this fail, since this GDB is linked with
libiconv.  Tom, can I get some guidance for how to dig deeper into
this?

The test in scoped_fd-selftests.c fails because it does something
MS-Windows doesn't support:

  ::scoped_fd sfd (gdb_mkostemp_cloexec (filename));
  SELF_CHECK (sfd.get () >= 0);

  unlink (filename);

  gdb_file_up file = sfd.to_file ("rw");
  SELF_CHECK (file != nullptr);

Gnulib's mkostemp opens the file with O_RDRW; according to MS
documentation of fdopen, here:

  https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fdopen-wfdopen?view=vs-2019

fdopen fails if the MODE argument doesn't match the original open mode
of the file descriptor, so we must use "r+", not "rw" (which isn't
supported according to the MS docs).  The second patch below fixes
that failure.

Btw, all the tests in scoped_fd-selftests.c call unlink to delete the
temporary file before closing its descriptor.  Is that necessary for
the tests to work correctly?  On Windows these unlink calls all fail,
and the resulting temporary files are left behind and clutter the
directory.  If possible, I'd like to move them after we close the
file.  Is it okay to submit a patch which will do that on all
platforms?

The format_pieces-selftests.c failure is due to the %lld, %llx, and
similar descriptors that test 'long long' formats.  The reason is
clearly seen in the debugger, for this test:

  static void
  test_format_specifier ()
  {
    /* The format string here ends with a % sequence, to ensure we don't
       see a trailing empty literal piece.  */
    check ("Hello\\t %d%llx%%d%d", /* ARI: %ll */
      {
	format_piece ("Hello\t ", literal_piece, 0),
	format_piece ("%d", int_arg, 0),
	format_piece ("%llx", long_long_arg, 0), /* ARI: %ll */
	format_piece ("%%d", literal_piece, 0),
	format_piece ("%d", int_arg, 0),
      });
  }

Here's the relevant part of the debug session:

  (top-gdb) p pieces.m_pieces
  $2 = {<std::_Vector_base<format_piece, std::allocator<format_piece> >> = {
      _M_impl = {<std::allocator<format_piece>> = {<__gnu_cxx::new_allocator<format_piece>> = {<No data fields>}, <No data fields>}, _M_start = 0x178c5f98,
	_M_finish = 0x178c5fd4,
	_M_end_of_storage = 0x178c5ff8}}, <No data fields>}
  (top-gdb) p pieces.m_pieces._M_impl._M_start
  $3 = (std::_Vector_base<format_piece, std::allocator<format_piece> >::pointer) 0x178c5f98
  (top-gdb) p *pieces.m_pieces._M_impl._M_start
  $4 = {string = 0x178c5ad0 "Hello\t ", argclass = literal_piece,
    n_int_args = 0}
  (top-gdb) p pieces.m_pieces._M_impl._M_start[1]
  $5 = {string = 0x178c5ad8 "%d", argclass = int_arg, n_int_args = 0}
  (top-gdb) p pieces.m_pieces._M_impl._M_start[2]
  $6 = {string = 0x178c5adc "%I64x", argclass = long_long_arg, n_int_args = 0}
  (top-gdb) p pieces.m_pieces._M_impl._M_start[3]
  $7 = {string = 0x178c5ae2 "%%d", argclass = literal_piece, n_int_args = 0}
  (top-gdb) p pieces.m_pieces._M_impl._M_start[4]
  $8 = {string = 0x178c5ae6 "%d", argclass = int_arg, n_int_args = 0}

As you see, we replace "%llx" with "%I64x", and the comparison then
fails.  Would it be okay to fix this by providing a different
expected_pieces when USE_PRINTF_I64 is non-zero?

Here are the two patches I propose; ok to commit (with the
appropriate log messages)?

--- gdb/utils.c~	2020-06-29 04:47:10.000000000 +0300
+++ gdb/utils.c	2020-07-02 16:11:45.476031500 +0300
@@ -2967,8 +2967,20 @@ gdb_realpath_check_trailer (const char *
   size_t len = strlen (result.get ());
   size_t trail_len = strlen (trailer);
 
+#ifndef _WIN32
   SELF_CHECK (len >= trail_len
 	      && strcmp (result.get () + len - trail_len, trailer) == 0);
+#else
+  const char *res_trail = result.get () + len - trail_len;
+  int slash = res_trail[0];
+
+  SELF_CHECK (len >= trail_len
+	      && (strcmp (result.get () + len - trail_len, trailer) == 0
+		  || (strcmp (result.get () + len - trail_len + 1,
+			      trailer + 1) == 0
+		      && IS_DIR_SEPARATOR (slash)
+		      && IS_DIR_SEPARATOR (trailer[0]))));
+#endif
 }
 
 static void
--- gdb/unittests/scoped_fd-selftests.c~	2020-06-29 04:47:10.000000000 +0300
+++ gdb/unittests/scoped_fd-selftests.c	2020-07-02 16:30:55.733738900 +0300
@@ -76,7 +76,7 @@ test_to_file ()
 
   unlink (filename);
   
-  gdb_file_up file = sfd.to_file ("rw");
+  gdb_file_up file = sfd.to_file ("r+");
   SELF_CHECK (file != nullptr);
   SELF_CHECK (sfd.get () == -1);
 }

Re: Building today's snapshot of GDB with MinGW

[Eli Zaretskii]

> Date: Thu, 02 Jul 2020 17:12:44 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: Joel Brobecker <brobecker@adacore.com>
> 
>   (top-gdb) p pieces.m_pieces._M_impl._M_start[1]
>   $5 = {string = 0x178c5ad8 "%d", argclass = int_arg, n_int_args = 0}
>   (top-gdb) p pieces.m_pieces._M_impl._M_start[2]
>   $6 = {string = 0x178c5adc "%I64x", argclass = long_long_arg, n_int_args = 0}
> 
> As you see, we replace "%llx" with "%I64x", and the comparison then
> fails.  Would it be okay to fix this by providing a different
> expected_pieces when USE_PRINTF_I64 is non-zero?

Actually, USE_PRINTF_I64 seems to be zero in my build, so I don't
really see why does format.cc replace "%llx" with "%I64x".  Could
someone please help me see that which I'm missing here?