[PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[SiZiOUS]

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

This little patch was made to allow the compilation under the MinGW/MSYS legacy environment (I don't know for the newer MinGW-w64/MSYS2 environment!).
If this patch is not applied, then the compilation of gdb-7.12.1 under MinGW/MSYS is impossible.

This fix is not intrusive as it's taken into account only if ERROR_IO_PENDING is not declared in the current scope, so it should be considered safe.
See the Bugzilla bug entry for more details.

Please note, this fix only allows the build possible under MinGW/MSYS, there is no bug fixes or improvements for GDB itself.

gdb/ChangeLog:
2018-08-28  SiZiOUS<sizious@gmail.com>

	PR build/23568
	* ser-mingw.c: Conditioned fix allowing compilation under
	the MinGW/MSYS legacy environment ('ERROR_IO_PENDING' was not
	declared in the scope).
  


[-- Attachment #2: ser-mingw.diff --]
[-- Type: text/plain, Size: 269 bytes --]

--- ser-mingw.c	2017-01-21 13:46:47 +0000
+++ ser-mingw.c-pr_build_23568	2018-08-28 11:44:38 +0000
@@ -31,6 +31,10 @@
 
 #include "command.h"
 
+#ifndef ERROR_IO_PENDING
+#include <winerror.h>
+#endif
+
 void _initialize_ser_windows (void);
 
 struct ser_windows_state

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[Pedro Alves]

Hi,

On 08/28/2018 01:01 PM, SiZiOUS wrote:
> This little patch was made to allow the compilation under the MinGW/MSYS legacy environment (I don't know for the newer MinGW-w64/MSYS2 environment!).
> If this patch is not applied, then the compilation of gdb-7.12.1 under MinGW/MSYS is impossible.

GDB 7.12 is old by now and not actively maintained.

Can you check whether this is necessary on the master branch?

Also, it's a bit curious that nobody else ran into this so far.   Could it
be you're using an older mingw and that the issue has been fixed in the
mingw/w32api headers meanwhile?

> This fix is not intrusive as it's taken into account only if ERROR_IO_PENDING is not declared in the current scope, so it should be considered safe.
> See the Bugzilla bug entry for more details.
> 
> Please note, this fix only allows the build possible under MinGW/MSYS, there is no bug fixes or improvements for GDB itself.
> 
> gdb/ChangeLog:
> 2018-08-28  SiZiOUS<sizious@gmail.com>
> 
>     PR build/23568
>     * ser-mingw.c: Conditioned fix allowing compilation under
>     the MinGW/MSYS legacy environment ('ERROR_IO_PENDING' was not
>     declared in the scope).

Thanks,
Pedro Alves

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[Eli Zaretskii]

> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 28 Aug 2018 17:57:43 +0100
> 
> On 08/28/2018 01:01 PM, SiZiOUS wrote:
> > This little patch was made to allow the compilation under the MinGW/MSYS legacy environment (I don't know for the newer MinGW-w64/MSYS2 environment!).
> > If this patch is not applied, then the compilation of gdb-7.12.1 under MinGW/MSYS is impossible.
> 
> GDB 7.12 is old by now and not actively maintained.
> 
> Can you check whether this is necessary on the master branch?

AFAICS, we include winerror.h via serial.h, which includes winsock2.h,
which includes winerror.h.  Older MinGW included that via the chain
windows.h->windef.h->winnt.h.

SiZiOUS, what version of the MinGW runtime are you using?

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[SiZiOUS]

Hello,

Thank you very much for your interest to my patch.

I'm using the MinGW/MSYS installer from the official SourceForge page: 
https://sourceforge.net/projects/mingw/

Please note, I'm using the original MinGW/MSYS environment, not the 
newer MinGW-w64/MSYS2 environment which is a completely new project, 
with no links from the original one.
The problem for me with MinGW-w64/MSYS2 is they dropped Windows XP 
support (and I understand that) but for my purpose I need XP support, as 
I targetting an old exotic platform (Sega Dreamcast if you're 
wondering), so I'm targetting GDB with sh-elf (fyi it's a Hitachi SH-4 CPU).

I did a new try on a completely fresh MinGW/MSYS installation just to be 
sure:

1- Download "mingw-get-setup.exe" from 
https://sourceforge.net/projects/mingw/ - it shows 
v0.6.2-beta-20131004-1 (It's just the MinGW Installation Manager Setup 
Tool version).
2- Click Install.
3- Install packages : mingw32-base, mingw32-gcc-g++, msys-base. GCC is 
6.3.0-1.
4- Open MSYS Shell.
5- Unpack gdb-7.12.1 in the home directory or somewhere else.
6- Then execute the following command to launch the GDB build: 
"configure --disable-werror --prefix=/opt/toolchains/dc/sh-elf 
--target=sh-elf", followed by "make".

If you not apply my patch, then you'll get the following error near the 
build end:

ser-mingw.c: In function 'int ser_windows_read_prim(serial*, size_t)':
ser-mingw.c:346:30: error: 'ERROR_IO_PENDING' was not declared in this scope
        if (GetLastError () != ERROR_IO_PENDING
                               ^~~~~~~~~~~~~~~~
ser-mingw.c: In function 'int ser_windows_write_prim(serial*, const 
void*, size_t)':
ser-mingw.c:368:30: error: 'ERROR_IO_PENDING' was not declared in this scope
        if (GetLastError () != ERROR_IO_PENDING
                               ^~~~~~~~~~~~~~~~
make[2]: *** [ser-mingw.o] Error 1

I tried the latest 8.0 build but it doesn't compile too.
Anyway I'm sticking to the 7.x branch as the GDB 7.x is confirmed to 
work with the Sega Dreamcast platform.

And I know, the MinGW/MSYS original project is maintained but almost 
deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP 
support for my needs.
I proposed this patch because it's really simple and not intrusive, but 
you're right, how many people uses that old MinGW/MSYS project?

Thank you for reading me in all the cases!

BR,
SiZiOUS

Le 28/08/2018 à 19:22, Eli Zaretskii a écrit :
>> From: Pedro Alves <palves@redhat.com>
>> Date: Tue, 28 Aug 2018 17:57:43 +0100
>>
>> On 08/28/2018 01:01 PM, SiZiOUS wrote:
>>> This little patch was made to allow the compilation under the MinGW/MSYS legacy environment (I don't know for the newer MinGW-w64/MSYS2 environment!).
>>> If this patch is not applied, then the compilation of gdb-7.12.1 under MinGW/MSYS is impossible.
>> GDB 7.12 is old by now and not actively maintained.
>>
>> Can you check whether this is necessary on the master branch?
> AFAICS, we include winerror.h via serial.h, which includes winsock2.h,
> which includes winerror.h.  Older MinGW included that via the chain
> windows.h->windef.h->winnt.h.
>
> SiZiOUS, what version of the MinGW runtime are you using?

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[SiZiOUS]

Hi there,

Just for your information, I tried to build gdb-8.1.1 under MinGW/MSYS 
and it doesn't work, due to a similar reason.
I opened a bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23583

Have a nice day.
M. Laranjeira

Le 29/08/2018 à 00:19, SiZiOUS a écrit :
> Hello,
>
> Thank you very much for your interest to my patch.
>
> I'm using the MinGW/MSYS installer from the official SourceForge page: 
> https://sourceforge.net/projects/mingw/
>
> Please note, I'm using the original MinGW/MSYS environment, not the 
> newer MinGW-w64/MSYS2 environment which is a completely new project, 
> with no links from the original one.
> The problem for me with MinGW-w64/MSYS2 is they dropped Windows XP 
> support (and I understand that) but for my purpose I need XP support, 
> as I targetting an old exotic platform (Sega Dreamcast if you're 
> wondering), so I'm targetting GDB with sh-elf (fyi it's a Hitachi SH-4 
> CPU).
>
> I did a new try on a completely fresh MinGW/MSYS installation just to 
> be sure:
>
> 1- Download "mingw-get-setup.exe" from 
> https://sourceforge.net/projects/mingw/ - it shows 
> v0.6.2-beta-20131004-1 (It's just the MinGW Installation Manager Setup 
> Tool version).
> 2- Click Install.
> 3- Install packages : mingw32-base, mingw32-gcc-g++, msys-base. GCC is 
> 6.3.0-1.
> 4- Open MSYS Shell.
> 5- Unpack gdb-7.12.1 in the home directory or somewhere else.
> 6- Then execute the following command to launch the GDB build: 
> "configure --disable-werror --prefix=/opt/toolchains/dc/sh-elf 
> --target=sh-elf", followed by "make".
>
> If you not apply my patch, then you'll get the following error near 
> the build end:
>
> ser-mingw.c: In function 'int ser_windows_read_prim(serial*, size_t)':
> ser-mingw.c:346:30: error: 'ERROR_IO_PENDING' was not declared in this 
> scope
>        if (GetLastError () != ERROR_IO_PENDING
>                               ^~~~~~~~~~~~~~~~
> ser-mingw.c: In function 'int ser_windows_write_prim(serial*, const 
> void*, size_t)':
> ser-mingw.c:368:30: error: 'ERROR_IO_PENDING' was not declared in this 
> scope
>        if (GetLastError () != ERROR_IO_PENDING
>                               ^~~~~~~~~~~~~~~~
> make[2]: *** [ser-mingw.o] Error 1
>
> I tried the latest 8.0 build but it doesn't compile too.
> Anyway I'm sticking to the 7.x branch as the GDB 7.x is confirmed to 
> work with the Sega Dreamcast platform.
>
> And I know, the MinGW/MSYS original project is maintained but almost 
> deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP 
> support for my needs.
> I proposed this patch because it's really simple and not intrusive, 
> but you're right, how many people uses that old MinGW/MSYS project?
>
> Thank you for reading me in all the cases!
>
> BR,
> SiZiOUS
>
> Le 28/08/2018 à 19:22, Eli Zaretskii a écrit :
>>> From: Pedro Alves <palves@redhat.com>
>>> Date: Tue, 28 Aug 2018 17:57:43 +0100
>>>
>>> On 08/28/2018 01:01 PM, SiZiOUS wrote:
>>>> This little patch was made to allow the compilation under the 
>>>> MinGW/MSYS legacy environment (I don't know for the newer 
>>>> MinGW-w64/MSYS2 environment!).
>>>> If this patch is not applied, then the compilation of gdb-7.12.1 
>>>> under MinGW/MSYS is impossible.
>>> GDB 7.12 is old by now and not actively maintained.
>>>
>>> Can you check whether this is necessary on the master branch?
>> AFAICS, we include winerror.h via serial.h, which includes winsock2.h,
>> which includes winerror.h.  Older MinGW included that via the chain
>> windows.h->windef.h->winnt.h.
>>
>> SiZiOUS, what version of the MinGW runtime are you using?
>

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[Eli Zaretskii]

> From: SiZiOUS <sizious@gmail.com>
> Cc: gdb-patches@sourceware.org
> Date: Wed, 29 Aug 2018 10:04:20 +0200
> 
> Just for your information, I tried to build gdb-8.1.1 under MinGW/MSYS 
> and it doesn't work, due to a similar reason.
> I opened a bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23583

FWIW, building GDB 8.2 with the latest version 5.1.1 of the MinGW
runtime and w32 API headers doesn't have this problem, it builds
cleanly (modulo a few harmless warnings).  So I suggest to upgrade to
the latest MinGW headers.

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[SiZiOUS]

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

Hello,

Long time no see, sorry for this delay.
Thanks for the information, about the 5.1.1 of the MinGW runtime and 
Win32 API headers.

This is really strange, I don't get it. The official mingw-get-setup 
tool from the official repo (https://fr.osdn.net/projects/mingw/) are 
using manifest files in date of 20170905, i.e. the MinGW runtime I use 
is 5.0.2.
So why making an update tool that doesn't do any updates sounds strange 
to me. So definitely my issue is related to the MinGW project update 
policy I guess.

By the way I finally moved from 7.12.1 to GDB 8.2 as I had a severe bug 
with remote debugging through a gdb stub (something related to a 'tp' 
thread assertion error).
So I tried to compile GDB 8.2 with that (outdated?! but out-of-the-box!) 
MinGW environment and still have errors related to winsock2.
So I made a diff patch to add some non-destructive instructions that 
you'll find attached. Feel free to use it or not.

If you wouldn't mind, I have a little question about remote debugging.
What's the proper way to tell the gdb client the fact that the remote 
process has ended?
If I understand well, I just need to close the connection (i.e. closing 
the socket). But sometimes it's working (i.e. gdb client shows "Remote 
connection ended") and sometimes it won't (gdb shows "Remote 
communication error: Not a directory" or "Remote communication error: No 
such file or directory").

I have the following:
target process ("hello.elf") <-----> application uploader/runner 
("dc-tool.exe") <-----> gdb client ("sh-elf-gdb")
target arch (sh-elf)                   |         host arch (pc win32)

dc-tool is a custom program which is reponsible to upload and execute 
the program on the target. gdb client passes through it to interact with 
the target program.
That means, the gdb server handling is in the dc-tool program.

I think part of the answer is the notification packet: 
https://sourceware.org/gdb/onlinedocs/gdb/Notification-Packets.html#Notification-Packets 

But I don't know if it's true and I don't know how to implement this.

Thank you for your time.

BR,
Mike
>
> Le 09/09/2018 à 22:06, Eli Zaretskii a écrit :
>>> From: SiZiOUS<sizious@gmail.com>
>>> Cc:gdb-patches@sourceware.org
>>> Date: Wed, 29 Aug 2018 10:04:20 +0200
>>>
>>> Just for your information, I tried to build gdb-8.1.1 under MinGW/MSYS
>>> and it doesn't work, due to a similar reason.
>>> I opened a bug:https://sourceware.org/bugzilla/show_bug.cgi?id=23583
>> FWIW, building GDB 8.2 with the latest version 5.1.1 of the MinGW
>> runtime and w32 API headers doesn't have this problem, it builds
>> cleanly (modulo a few harmless warnings).  So I suggest to upgrade to
>> the latest MinGW headers.
>


[-- Attachment #2: gdb-8.2.diff --]
[-- Type: text/plain, Size: 847 bytes --]

diff -ruN gdb-8.2/gdb/gnulib/import/strerror-override.c gdb-8.2-mingw/gdb/gnulib/import/strerror-override.c
--- gdb-8.2/gdb/gnulib/import/strerror-override.c	2018-09-05 07:44:28 +0000
+++ gdb-8.2-mingw/gdb/gnulib/import/strerror-override.c	2018-11-30 19:37:03 +0000
@@ -25,6 +25,9 @@
 
 #if GNULIB_defined_EWINSOCK /* native Windows platforms */
 # if HAVE_WINSOCK2_H
+#  ifdef __MINGW32__
+#  include <winerror.h>
+#  endif
 #  include <winsock2.h>
 # endif
 #endif
diff -ruN gdb-8.2/gdb/ser-mingw.c gdb-8.2-mingw/gdb/ser-mingw.c
--- gdb-8.2/gdb/ser-mingw.c	2018-09-05 07:44:28 +0000
+++ gdb-8.2-mingw/gdb/ser-mingw.c	2018-11-30 19:57:46 +0000
@@ -29,6 +29,10 @@
 #include <unistd.h>
 #include <sys/types.h>
 
+#ifndef ERROR_IO_PENDING
+#include <winerror.h>
+#endif
+
 #include "command.h"
 
 struct ser_windows_state

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[Simon Marchi]

On 2018-08-28 18:19, SiZiOUS wrote:
> Please note, I'm using the original MinGW/MSYS environment, not the
> newer MinGW-w64/MSYS2 environment which is a completely new project,
> with no links from the original one.
> The problem for me with MinGW-w64/MSYS2 is they dropped Windows XP
> support (and I understand that) but for my purpose I need XP support,
> as I targetting an old exotic platform (Sega Dreamcast if you're
> wondering), so I'm targetting GDB with sh-elf (fyi it's a Hitachi SH-4
> CPU).

That sounds awesome :).  You are working with real hardware?  You need 
Windows XP because that's what the original tools for that platform 
support?

> ser-mingw.c: In function 'int ser_windows_read_prim(serial*, size_t)':
> ser-mingw.c:346:30: error: 'ERROR_IO_PENDING' was not declared in this 
> scope
>        if (GetLastError () != ERROR_IO_PENDING
>                               ^~~~~~~~~~~~~~~~
> ser-mingw.c: In function 'int ser_windows_write_prim(serial*, const
> void*, size_t)':
> ser-mingw.c:368:30: error: 'ERROR_IO_PENDING' was not declared in this 
> scope
>        if (GetLastError () != ERROR_IO_PENDING
>                               ^~~~~~~~~~~~~~~~
> make[2]: *** [ser-mingw.o] Error 1

If this constant is supposed to be defined in the win32 API but is 
missing with mingw, could it be that it's more of a mingw bug, and it 
should be fixed there?

> I tried the latest 8.0 build but it doesn't compile too.
> Anyway I'm sticking to the 7.x branch as the GDB 7.x is confirmed to
> work with the Sega Dreamcast platform.

Just wondering, which 7.x version is confirmed to work with that 
platform?  Functionality-wise, there's no more difference between the 
7.12 and 8.0 releases, for example, than there are between 7.11 and 
7.12.  The numbers are pretty much arbitrary.  So let's say GDB 7.6 was 
known to work, there's no reason to use 7.12 over what is the latest 
released GDB at the moment (unless you actually have a problem with the 
latest release, in which case we want to know!).

> And I know, the MinGW/MSYS original project is maintained but almost
> deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP
> support for my needs.
> I proposed this patch because it's really simple and not intrusive,
> but you're right, how many people uses that old MinGW/MSYS project?

If the missing definition is indeed a mingw bug, but there is really no 
way of getting a new mingw release with that fixed because the project 
is unmaintained (but still useful to some people), I would not be 
against a patch like what you proposed.  I would however add a clear 
comment for why this is needed, so that if some day we officially decide 
not to support this mingw, we can remove it.

Simon

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[Eli Zaretskii]

> Date: Wed, 29 Aug 2018 11:50:43 -0400
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>, Pedro Alves <palves@redhat.com>,
>         gdb-patches@sourceware.org
> 
> > ser-mingw.c:368:30: error: 'ERROR_IO_PENDING' was not declared in this 
> > scope
> >        if (GetLastError () != ERROR_IO_PENDING
> >                               ^~~~~~~~~~~~~~~~
> > make[2]: *** [ser-mingw.o] Error 1
> 
> If this constant is supposed to be defined in the win32 API but is 
> missing with mingw, could it be that it's more of a mingw bug, and it 
> should be fixed there?

It is not a MinGW bug: this constant is defined in winerror.h that
comes with MinGW's w32api package.

The problem seems to be that winerror.h somehow doesn't get included
in that source file, neither directly nor indirectly.  I will try to
look into it some time soon.

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[Tom Tromey]

>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:

>> And I know, the MinGW/MSYS original project is maintained but almost
>> deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP
>> support for my needs.
>> I proposed this patch because it's really simple and not intrusive,
>> but you're right, how many people uses that old MinGW/MSYS project?

Simon> If the missing definition is indeed a mingw bug, but there is really
Simon> no way of getting a new mingw release with that fixed because the
Simon> project is unmaintained (but still useful to some people), I would not
Simon> be against a patch like what you proposed.  I would however add a
Simon> clear comment for why this is needed, so that if some day we
Simon> officially decide not to support this mingw, we can remove it.

Also, is there any downside to the original patch?
If not then I think we might as well accept it, subject to Simon's
request here.

Tom

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[SiZiOUS]

Le 29/08/2018 à 18:24, Tom Tromey a écrit :
>>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:
>>> And I know, the MinGW/MSYS original project is maintained but almost
>>> deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP
>>> support for my needs.
>>> I proposed this patch because it's really simple and not intrusive,
>>> but you're right, how many people uses that old MinGW/MSYS project?
> Simon> If the missing definition is indeed a mingw bug, but there is really
> Simon> no way of getting a new mingw release with that fixed because the
> Simon> project is unmaintained (but still useful to some people), I would not
> Simon> be against a patch like what you proposed.  I would however add a
> Simon> clear comment for why this is needed, so that if some day we
> Simon> officially decide not to support this mingw, we can remove it.
>
> Also, is there any downside to the original patch?
> If not then I think we might as well accept it, subject to Simon's
> request here.
Nope, as it only includes the winerror.h header file just in case that 
the ERROR_IO_PENDING is undefined.
So if ERROR_IO_PENDING is defined (as it would be normally), my patch 
does nothing.
>
> Tom

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[Pedro Alves]

On 08/29/2018 05:24 PM, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:
> 
>>> And I know, the MinGW/MSYS original project is maintained but almost
>>> deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP
>>> support for my needs.
>>> I proposed this patch because it's really simple and not intrusive,
>>> but you're right, how many people uses that old MinGW/MSYS project?
> 
> Simon> If the missing definition is indeed a mingw bug, but there is really
> Simon> no way of getting a new mingw release with that fixed because the
> Simon> project is unmaintained (but still useful to some people), I would not
> Simon> be against a patch like what you proposed.  I would however add a
> Simon> clear comment for why this is needed, so that if some day we
> Simon> officially decide not to support this mingw, we can remove it.
> 
> Also, is there any downside to the original patch?
> If not then I think we might as well accept it, subject to Simon's
> request here.

AFAICT, we don't know for sure whether it's necessary on the master
branch.  The issue reported at <https://sourceware.org/bugzilla/show_bug.cgi?id=23583>
seems similar, but the patch will not fix it, making it pointless on its own.

It's possible that identifying a fix for the gnulib side may reveal
a different fix for the gdb side accordingly.

SiZiOUS can you try building the git master branch, or a recent
snapshot?  See:

  https://sourceware.org/gdb/current/

For example: 
  ftp://sourceware.org/pub/gdb/snapshots/current/gdb-8.2.50.20180829.tar.xz

The best would be current git master (or wait for a snapshot tomorrow),
because we just updated the gnulib copy in our tree.

Also, why do we need the #ifndef?  Would unconditionally
include winerr.h cause problems?

Thanks,
Pedro Alves

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[SiZiOUS]

Hi Simon!

Le 29/08/2018 à 17:50, Simon Marchi a écrit :
> On 2018-08-28 18:19, SiZiOUS wrote:
>> Please note, I'm using the original MinGW/MSYS environment, not the
>> newer MinGW-w64/MSYS2 environment which is a completely new project,
>> with no links from the original one.
>> The problem for me with MinGW-w64/MSYS2 is they dropped Windows XP
>> support (and I understand that) but for my purpose I need XP support,
>> as I targetting an old exotic platform (Sega Dreamcast if you're
>> wondering), so I'm targetting GDB with sh-elf (fyi it's a Hitachi SH-4
>> CPU).
>
> That sounds awesome :).  You are working with real hardware? 
Yes, I'm working on the real hardware as I'm a Sega Dreamcast enthusiasm 
for at least 20 years. And we all love old stuffs, right? ;)
> You need Windows XP because that's what the original tools for that 
> platform support?
You pointed at it. The Sega Dreamcast was released back in '98, so the 
golden era of Windows 98 and NT/2K/XP. XP is old today but it's still 
usable (unlike 98/NT/2K...).
So I own a modern setup for my daily usage (Windows 10) and an old 
workstation with XP dedicated for my Sega Dreamcast development sessions.

But I don't use the official Sega SDK for legal reasons and mainly 
because the tools are really old. But as my Dreamcast hardware is 
connected to my XP computer throught an old COM port, and there is some 
old tools that works only on XP, I'm stick with that environment for 
that usage. That's why I'm still using the old MinGW/MSYS project 
instead of the newer (and really good) MinGW-w64/MSYS2.
>
>> ser-mingw.c: In function 'int ser_windows_read_prim(serial*, size_t)':
>> ser-mingw.c:346:30: error: 'ERROR_IO_PENDING' was not declared in 
>> this scope
>>        if (GetLastError () != ERROR_IO_PENDING
>>                               ^~~~~~~~~~~~~~~~
>> ser-mingw.c: In function 'int ser_windows_write_prim(serial*, const
>> void*, size_t)':
>> ser-mingw.c:368:30: error: 'ERROR_IO_PENDING' was not declared in 
>> this scope
>>        if (GetLastError () != ERROR_IO_PENDING
>>                               ^~~~~~~~~~~~~~~~
>> make[2]: *** [ser-mingw.o] Error 1
>
> If this constant is supposed to be defined in the win32 API but is 
> missing with mingw, could it be that it's more of a mingw bug, and it 
> should be fixed there?
It's defined in winerror.h in the W32API package but for an unknown 
reason it isn't taken into account when compiling GDB.
So that's the fix: if the constant is undefined for some reason, I force 
the inclusion of it. That's why I'm calling this little fix "not 
intrusive". Not doing so will prevent the compilation of GDB anyway.
>
>> I tried the latest 8.0 build but it doesn't compile too.
>> Anyway I'm sticking to the 7.x branch as the GDB 7.x is confirmed to
>> work with the Sega Dreamcast platform.
>
> Just wondering, which 7.x version is confirmed to work with that 
> platform?  Functionality-wise, there's no more difference between the 
> 7.12 and 8.0 releases, for example, than there are between 7.11 and 
> 7.12.  The numbers are pretty much arbitrary.  So let's say GDB 7.6 
> was known to work, there's no reason to use 7.12 over what is the 
> latest released GDB at the moment (unless you actually have a problem 
> with the latest release, in which case we want to know!).
My thought was simpler.

In fact, I use the KallistiOS library which is an open source library 
that gives access to hardware resources of the Dreamcast from homebrew 
programs.
In that library, there is a complete Makefile (which doesn't work 
out-of-the-box for MinGW/MSYS, so that's the purpose of my work) setting 
up the complete toolchain for making Dreamcast apps.
In that Makefile (which is called "dc-chain" FYI), a lot of stuffs are 
made for setting up the development environment. We had some problems 
with newer versions of GCC, i.e. we used GCC 4.8.2 some time but it 
produces instable code for the Dreamcast, so the GCC version was 
reverted back to the 4.7.3 version. So I don't even think about updating 
to modern GCC...

I know this is the mailing list for GDB so talking about GCC here is 
unrevelant: the thing is, as you can see, the Dreamcast is old, exotic 
and I'm not surprised if GCC is not working properly.
So I was thinking the same for GDB.

But in fact, GDB 7.11.1 is confirmed to work. As this version isn't 
compiling under MinGW for some reason, I updated to the latest 7.x 
version, and the only issue I had was this little build problem.
I've not tested GDB now, so I don't know if it's work or not with the 
Dreamcast.

For the 8.x, I opened a bug about building on MinGW, but seems to be a 
similar reason.
>
>> And I know, the MinGW/MSYS original project is maintained but almost
>> deprecated in favour of MinGW-w64/MSYS2 project. But I really need XP
>> support for my needs.
>> I proposed this patch because it's really simple and not intrusive,
>> but you're right, how many people uses that old MinGW/MSYS project?
>
> If the missing definition is indeed a mingw bug, but there is really 
> no way of getting a new mingw release with that fixed because the 
> project is unmaintained (but still useful to some people), I would not 
> be against a patch like what you proposed.  I would however add a 
> clear comment for why this is needed, so that if some day we 
> officially decide not to support this mingw, we can remove it.
>
Up to you :)
I'm just proposing this patch as it was really simple to do and could 
help others (especially with basic "C/C++" skills, e.g. students...).
But I don't know if it's revelant for MinGW-w64/MSYS2 or not, but it's 
the case for at least the MinGW/MSYS project!
> Simon

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[Pedro Alves]

On 08/29/2018 05:59 PM, SiZiOUS wrote:
> 
> 
> But in fact, GDB 7.11.1 is confirmed to work. As this version isn't compiling under MinGW for some reason, I updated to the latest 7.x version, and the only issue I had was this little build problem.
> I've not tested GDB now, so I don't know if it's work or not with the Dreamcast.
> 
> For the 8.x, I opened a bug about building on MinGW, but seems to be a similar reason.

I think you're confused with GDB's release numbering.
The set of 7.x releases are not all part of a single maintenance "gdb 7"
tree/family. Likewise, set of 8.x releases are not all part of a
single maintenance "gdb 8" tree/family.  I.e., 7.12 is not a maintenance
release of 7.11.  7.11 is not a maintenance release of 7.10.  etc.

GDB 7.12 was just as much of an increase over 7.11, as 8.0 was over 7.12.
It just happened that when we got all the way up to "12" we though that
that would be a good time to roll over to 8.0, because small numbers are
nice.

Maintenance bugfix releases are instead the z in x.y.z, as in
7.11.1, 7.11.2, etc.

Currently, we're about to release gdb 8.2, so the 8.2.x branch
in git is open for regression bugfixes.  Build fixes like yours
would be a good fit too.  It's possible to merge fixes to older
branches, but it's not very usual.  As we move on to newer
releases, the older branches tend to become unmaintained.

Thanks,
Pedro Alves

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[SiZiOUS]

First of all, thank for your time!
Also thanks for the explanation, you're right, I was thinking 7.12 was 
maintenance release of 7.11 and I understand that isn't the case.

Just for your information, I tried as requested to compile the current 
version of gdb (gdb-8.2.50.20180829), just to know the results.
It doesn't compile:

   CXX    ser-tcp.o
ser-tcp.c:43:21: fatal error: wspiapi.h: No such file or directory
  #include <wspiapi.h>
                      ^
compilation terminated.
make[2]: *** [ser-tcp.o] Error 1

I searched this file in my MinGW install but no luck, so I went to 
Internet and found something:
https://groups.google.com/forum/#!topic/wx-dev/mquqPOh8fFs

That file doesn't exist on MinGW, but exists on MinGW-w64.

According to the post above, I tried to fix the issue with:

#ifdef __MINGW32__
#include <ws2spi.h>
#else
#include <wspiapi.h>
#endif

But new errors are coming:

   CXX    ser-tcp.o
ser-tcp.c: In function 'int try_connect(const addrinfo*, unsigned int*)':
ser-tcp.c:171:39: error: invalid use of incomplete type 'const struct 
addrinfo'
    int sock = gdb_socket_cloexec (ainfo->ai_family, ainfo->ai_socktype,
                                        ^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
    explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                          ^~~~~~~~
ser-tcp.c:171:57: error: invalid use of incomplete type 'const struct 
addrinfo'
    int sock = gdb_socket_cloexec (ainfo->ai_family, ainfo->ai_socktype,
                                                          ^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
    explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                          ^~~~~~~~
ser-tcp.c:172:11: error: invalid use of incomplete type 'const struct 
addrinfo'
       ainfo->ai_protocol);
            ^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
    explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                          ^~~~~~~~
ser-tcp.c:188:27: error: invalid use of incomplete type 'const struct 
addrinfo'
    if (connect (sock, ainfo->ai_addr, ainfo->ai_addrlen) < 0)
                            ^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
    explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                          ^~~~~~~~
ser-tcp.c:188:43: error: invalid use of incomplete type 'const struct 
addrinfo'
    if (connect (sock, ainfo->ai_addr, ainfo->ai_addrlen) < 0)
                                            ^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
    explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                          ^~~~~~~~
ser-tcp.c: In function 'int net_open(serial*, const char*)':
ser-tcp.c:283:19: error: aggregate 'addrinfo hint' has incomplete type 
and cannot be defined
    struct addrinfo hint;
                    ^~~~
ser-tcp.c:300:23: error: 'getaddrinfo' was not declared in this scope
           &hint, &ainfo);
                        ^
ser-tcp.c:305:27: error: 'gai_strerror' was not declared in this scope
       name, gai_strerror (r));
                            ^
ser-tcp.c:327:68: error: invalid use of incomplete type 'struct addrinfo'
        for (struct addrinfo *iter = ainfo; iter != NULL; iter = 
iter->ai_next)
^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
    explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                          ^~~~~~~~
ser-tcp.c:378:20: error: invalid use of incomplete type 'struct addrinfo'
    if (success_ainfo->ai_protocol == IPPROTO_TCP)
                     ^~
In file included from ser-tcp.c:28:0:
./common/netstuff.h:34:41: note: forward declaration of 'struct addrinfo'
    explicit scoped_free_addrinfo (struct addrinfo *ainfo)
                                          ^~~~~~~~
make[2]: *** [ser-tcp.o] Error 1

So this time, fixing GDB for MinGW is harder than 7.12.1.
Too tired to do that now.

Have a good night,
Mike Laranjeira (SiZiOUS)

Le 29/08/2018 à 20:27, Pedro Alves a écrit :
> On 08/29/2018 05:59 PM, SiZiOUS wrote:
>>
>> But in fact, GDB 7.11.1 is confirmed to work. As this version isn't compiling under MinGW for some reason, I updated to the latest 7.x version, and the only issue I had was this little build problem.
>> I've not tested GDB now, so I don't know if it's work or not with the Dreamcast.
>>
>> For the 8.x, I opened a bug about building on MinGW, but seems to be a similar reason.
> I think you're confused with GDB's release numbering.
> The set of 7.x releases are not all part of a single maintenance "gdb 7"
> tree/family. Likewise, set of 8.x releases are not all part of a
> single maintenance "gdb 8" tree/family.  I.e., 7.12 is not a maintenance
> release of 7.11.  7.11 is not a maintenance release of 7.10.  etc.
>
> GDB 7.12 was just as much of an increase over 7.11, as 8.0 was over 7.12.
> It just happened that when we got all the way up to "12" we though that
> that would be a good time to roll over to 8.0, because small numbers are
> nice.
>
> Maintenance bugfix releases are instead the z in x.y.z, as in
> 7.11.1, 7.11.2, etc.
>
> Currently, we're about to release gdb 8.2, so the 8.2.x branch
> in git is open for regression bugfixes.  Build fixes like yours
> would be a good fit too.  It's possible to merge fixes to older
> branches, but it's not very usual.  As we move on to newer
> releases, the older branches tend to become unmaintained.
>
> Thanks,
> Pedro Alves

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[Pedro Alves]

On 08/29/2018 04:50 PM, Simon Marchi wrote:
> 
> If the missing definition is indeed a mingw bug, but there is really no way of getting a new mingw release with that fixed because the project is unmaintained (but still useful to some people), I would not be against a patch like what you proposed.  I would however add a clear comment for why this is needed, so that if some day we officially decide not to support this mingw, we can remove it.

Not sure about mingw.org (the original mingw) being unmaintained.
There seems to have been recent commits:
  https://sourceforge.net/p/mingw/mailman/mingw-cvs/

Thanks,
Pedro Alves

Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 29 Aug 2018 18:54:23 +0100
> 
> Not sure about mingw.org (the original mingw) being unmaintained.

It's definitely maintained.  Version 5.1 of the runtime was released 6
months ago and GCC 7.3.0 2 months ago.

> There seems to have been recent commits:
>   https://sourceforge.net/p/mingw/mailman/mingw-cvs/

Actually, the source tree is here:

  https://osdn.net/projects/mingw/scm/git/mingw-org-wsl