Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: SiZiOUS <sizious@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: palves@redhat.com, gdb-patches@sourceware.org
Subject: Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue
Date: Sun, 02 Dec 2018 13:52:00 -0000	[thread overview]
Message-ID: <c9c8ff23-a8ca-6a19-bae5-be12dcb64ad9@gmail.com> (raw)
In-Reply-To: <ddb12e03-7fc3-bf4b-cd24-235b43c33d38@gmail.com>

[-- 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

  parent reply	other threads:[~2018-12-02 13:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-28 12:01 SiZiOUS
2018-08-28 16:57 ` Pedro Alves
2018-08-28 17:22   ` Eli Zaretskii
2018-08-28 22:19     ` SiZiOUS
2018-08-29  8:04       ` SiZiOUS
2018-09-09 20:06         ` Eli Zaretskii
     [not found]           ` <ddb12e03-7fc3-bf4b-cd24-235b43c33d38@gmail.com>
2018-12-02 13:52             ` SiZiOUS [this message]
2018-08-29 15:50       ` Simon Marchi
2018-08-29 16:19         ` Eli Zaretskii
2018-08-29 16:25         ` Tom Tromey
2018-08-29 17:01           ` SiZiOUS
2018-08-29 17:46           ` Pedro Alves
2018-08-29 16:59         ` SiZiOUS
2018-08-29 18:27           ` Pedro Alves
2018-08-29 21:07             ` SiZiOUS
2018-08-29 17:54         ` Pedro Alves
2018-08-29 18:09           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c9c8ff23-a8ca-6a19-bae5-be12dcb64ad9@gmail.com \
    --to=sizious@gmail.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox