From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2448 invoked by alias); 2 Dec 2018 13:52:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 2432 invoked by uid 89); 2 Dec 2018 13:52:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:mail-wm, HX-Received:c303 X-HELO: mail-wm1-f52.google.com Received: from mail-wm1-f52.google.com (HELO mail-wm1-f52.google.com) (209.85.128.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 02 Dec 2018 13:52:08 +0000 Received: by mail-wm1-f52.google.com with SMTP id y139so3140752wmc.5 for ; Sun, 02 Dec 2018 05:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=oU+maHxk3q8rSTCYI1hgVGUH+135hmKueJmvlkUYVuk=; b=FLASKm0KZH8UnCELvcz0If4o0wbIYtL2EkiLskPrv5+gfOCNj2izxSp/Mf9/+VDRGk K6ZkPvDTd/IOUMXpqasyxByLmD1xMnXY8dxmXCX8qiMhTyR9PSMMZMWXNwN28Qn8haYS 68kPY71qvabjiKqV5G1YpUyDxdOnyJaL8RHAlBIyyXVhNvGJrA9fSi07QAzudibvnA99 zOFn896X3CvQYsZSccYfqq2dS/WKfgf+Ybn00GLm0hHvorDC/cMGDlfAdohgugdsfbdr eWBLd5wIuGRRLpqbOCEZ1qy7jwJ3tOmMevIGbm9sZoLgtZCBYnk3LmsOCEqnADz7SB6b KIUQ== Return-Path: Received: from ?IPv6:2a01:e35:2eac:2a80:5d8a:a6a1:bace:bb6a? ([2a01:e35:2eac:2a80:5d8a:a6a1:bace:bb6a]) by smtp.gmail.com with ESMTPSA id h12sm13713267wma.48.2018.12.02.05.52.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Dec 2018 05:52:05 -0800 (PST) Subject: Re: [PATCH][PR build/23568] Fix gdb-7.12.1 MinGW/MSYS build issue From: SiZiOUS To: Eli Zaretskii Cc: palves@redhat.com, gdb-patches@sourceware.org References: <56c5911c-e0ba-5a17-64bb-3634af60a07d@gmail.com> <18eaf339-ca0a-061c-4a17-b837e6ef81a2@redhat.com> <83wosa2yos.fsf@gnu.org> <56153263-c5e6-45ce-8629-c5a77cf17f5b@gmail.com> <83y3capha5.fsf@gnu.org> Message-ID: Date: Sun, 02 Dec 2018 13:52:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------30A0DD3D93AFE2111C5755A8" X-SW-Source: 2018-12/txt/msg00012.txt.bz2 This is a multi-part message in MIME format. --------------30A0DD3D93AFE2111C5755A8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-length: 2744 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 >>> 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. > --------------30A0DD3D93AFE2111C5755A8 Content-Type: text/plain; charset=UTF-8; name="gdb-8.2.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gdb-8.2.diff" Content-length: 1151 ZGlmZiAtcnVOIGdkYi04LjIvZ2RiL2dudWxpYi9pbXBvcnQvc3RyZXJyb3It b3ZlcnJpZGUuYyBnZGItOC4yLW1pbmd3L2dkYi9nbnVsaWIvaW1wb3J0L3N0 cmVycm9yLW92ZXJyaWRlLmMNCi0tLSBnZGItOC4yL2dkYi9nbnVsaWIvaW1w b3J0L3N0cmVycm9yLW92ZXJyaWRlLmMJMjAxOC0wOS0wNSAwNzo0NDoyOCAr MDAwMA0KKysrIGdkYi04LjItbWluZ3cvZ2RiL2dudWxpYi9pbXBvcnQvc3Ry ZXJyb3Itb3ZlcnJpZGUuYwkyMDE4LTExLTMwIDE5OjM3OjAzICswMDAwDQpA QCAtMjUsNiArMjUsOSBAQA0KIA0KICNpZiBHTlVMSUJfZGVmaW5lZF9FV0lO U09DSyAvKiBuYXRpdmUgV2luZG93cyBwbGF0Zm9ybXMgKi8NCiAjIGlmIEhB VkVfV0lOU09DSzJfSA0KKyMgIGlmZGVmIF9fTUlOR1czMl9fDQorIyAgaW5j bHVkZSA8d2luZXJyb3IuaD4NCisjICBlbmRpZg0KICMgIGluY2x1ZGUgPHdp bnNvY2syLmg+DQogIyBlbmRpZg0KICNlbmRpZg0KZGlmZiAtcnVOIGdkYi04 LjIvZ2RiL3Nlci1taW5ndy5jIGdkYi04LjItbWluZ3cvZ2RiL3Nlci1taW5n dy5jDQotLS0gZ2RiLTguMi9nZGIvc2VyLW1pbmd3LmMJMjAxOC0wOS0wNSAw Nzo0NDoyOCArMDAwMA0KKysrIGdkYi04LjItbWluZ3cvZ2RiL3Nlci1taW5n dy5jCTIwMTgtMTEtMzAgMTk6NTc6NDYgKzAwMDANCkBAIC0yOSw2ICsyOSwx MCBAQA0KICNpbmNsdWRlIDx1bmlzdGQuaD4NCiAjaW5jbHVkZSA8c3lzL3R5 cGVzLmg+DQogDQorI2lmbmRlZiBFUlJPUl9JT19QRU5ESU5HDQorI2luY2x1 ZGUgPHdpbmVycm9yLmg+DQorI2VuZGlmDQorDQogI2luY2x1ZGUgImNvbW1h bmQuaCINCiANCiBzdHJ1Y3Qgc2VyX3dpbmRvd3Nfc3RhdGUNCg== --------------30A0DD3D93AFE2111C5755A8--