Building today's snapshot of GDB with MinGW

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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.
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Sourceware - gdb-patches mailing list
On Mon, Jun 29, 2020 at 1:27 PM Eli Zaretskii <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Eli Zaretskii
> From: Christian Biesinger <[hidden email]>
> Date: Mon, 29 Jun 2020 15:36:50 -0500
> Cc: gdb-patches <[hidden email]>
>
> > 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?
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Eli Zaretskii
In reply to this post by Eli Zaretskii
> Date: Mon, 29 Jun 2020 21:27:32 +0300
> From: Eli Zaretskii <[hidden email]>
>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Sourceware - gdb-patches mailing list
On Tue, Jun 30, 2020 at 11:18 AM Eli Zaretskii <[hidden email]> wrote:

>
> > Date: Mon, 29 Jun 2020 21:27:32 +0300
> > From: Eli Zaretskii <[hidden email]>
> >
> > 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
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Eli Zaretskii
> From: Christian Biesinger <[hidden email]>
> Date: Tue, 30 Jun 2020 13:21:44 -0500
> Cc: Joel Brobecker <[hidden email]>, gdb-patches <[hidden email]>
>
> > 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.
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Sourceware - gdb-patches mailing list
In reply to this post by Eli Zaretskii
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
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Eli Zaretskii
> Cc: [hidden email]
> From: Simon Marchi <[hidden email]>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Eli Zaretskii
In reply to this post by Sourceware - gdb-patches mailing list
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?
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Sourceware - gdb-patches mailing list
On Wed, Jul 1, 2020 at 10:20 AM Eli Zaretskii <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Joel Brobecker
In reply to this post by Eli Zaretskii
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
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Joel Brobecker
In reply to this post by Eli Zaretskii
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
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Joel Brobecker
In reply to this post by Eli Zaretskii
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Eli Zaretskii
In reply to this post by Sourceware - gdb-patches mailing list
> From: Christian Biesinger <[hidden email]>
> Date: Wed, 1 Jul 2020 14:25:22 -0500
> Cc: Simon Marchi <[hidden email]>, Tom Tromey <[hidden email]>,
> Joel Brobecker <[hidden email]>, gdb-patches <[hidden email]>
>
> >   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.
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Eli Zaretskii
In reply to this post by Joel Brobecker
> Date: Wed, 1 Jul 2020 12:29:13 -0700
> From: Joel Brobecker <[hidden email]>
> Cc: [hidden email]
>
> >   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.
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Hannes Domani
In reply to this post by Eli Zaretskii
 Am Donnerstag, 2. Juli 2020, 04:30:01 MESZ hat Eli Zaretskii <[hidden email]> Folgendes geschrieben:

> > From: Christian Biesinger <[hidden email]>
> > Date: Wed, 1 Jul 2020 14:25:22 -0500
> > Cc: Simon Marchi <[hidden email]>, Tom Tromey <[hidden email]>,
> >     Joel Brobecker <[hidden email]>, gdb-patches <[hidden email]>
> >
> > >  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
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Eli Zaretskii
> Date: Thu, 2 Jul 2020 10:18:20 +0000 (UTC)
> From: Hannes Domani <[hidden email]>
> Cc: [hidden email], [hidden email], [hidden email]
>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Eli Zaretskii
In reply to this post by Joel Brobecker
> Date: Wed, 1 Jul 2020 12:30:26 -0700
> From: Joel Brobecker <[hidden email]>
> Cc: [hidden email]
>
> >   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?
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Eli Zaretskii
In reply to this post by Joel Brobecker
> Date: Wed, 1 Jul 2020 12:25:41 -0700
> From: Joel Brobecker <[hidden email]>
> Cc: Christian Biesinger <[hidden email]>,
> Tom Tromey <[hidden email]>, [hidden email],
> [hidden email]
>
> > 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.
Reply | Threaded
Open this post in threaded view
|

Re: Building today's snapshot of GDB with MinGW

Eli Zaretskii
In reply to this post by Eli Zaretskii
> Date: Wed, 01 Jul 2020 18:09:11 +0300
> From: Eli Zaretskii <[hidden email]>
> Cc: [hidden email], [hidden email], [hidden email]
>
> > 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.
12