From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112866 invoked by alias); 13 Oct 2019 16:27:21 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 112859 invoked by uid 89); 13 Oct 2019 16:27:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FORGED_SPF_HELO,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=no version=3.3.1 spammy=IRC, irc, structures, person X-HELO: sa-prd-fep-043.btinternet.com Received: from mailomta30-sa.btinternet.com (HELO sa-prd-fep-043.btinternet.com) (213.120.69.36) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 13 Oct 2019 16:27:19 +0000 Received: from sa-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.38.5]) by sa-prd-fep-043.btinternet.com with ESMTP id <20191013162717.GFGP22185.sa-prd-fep-043.btinternet.com@sa-prd-rgout-002.btmx-prd.synchronoss.net>; Sun, 13 Oct 2019 17:27:17 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com X-OWM-Source-IP: 86.141.128.155 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean Received: from [192.168.1.102] (86.141.128.155) by sa-prd-rgout-002.btmx-prd.synchronoss.net (5.8.337) (authenticated as jonturney@btinternet.com) id 5D9605B501BBF297; Sun, 13 Oct 2019 17:27:17 +0100 From: Jon Turney Subject: Re: assert creates unusable core dump on current stable Cygwin release To: The Cygwin Mailing List References: <2300fe24-fc50-3d1c-6b1b-bf6da6022d2e@SystematicSw.ab.ca> <71be3508-b11e-4681-eac6-9d44845088c7@SystematicSw.ab.ca> <1ac90af2-412d-345f-da40-8260ae527096@dronecode.org.uk> <380e89cb-4e31-4af2-40ca-c143e6622424@SystematicSw.ab.ca> Cc: Brian.Inglis@SystematicSw.ab.ca Message-ID: <244f3cd4-59b5-e28a-cd9c-e23f6c259f59@dronecode.org.uk> Date: Sun, 13 Oct 2019 16:27:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <380e89cb-4e31-4af2-40ca-c143e6622424@SystematicSw.ab.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-10/txt/msg00071.txt.bz2 On 10/10/2019 23:20, Brian Inglis wrote: > On 2019-10-10 14:57, Csaba Raduly wrote: >> On Thu, Oct 10, 2019 at 9:19 PM Jon Turney wrote: >>> (and I guess this patch is not acceptable as-is, as it looks like it >>> would break x86) >> That was my reaction too. > > Obviously there would have to be some arch dependent conditional changes, but I You could do that. Then at least we'd have something to test. It might even 'just work'. > was hoping that someone with a clue about libbfd, could provide some hints as to > where else to look for more info on what other changes might be required, or > confirmation that this is object oriented enough to mainly just work with some > additional tweaks. I don't think the person who has an in-depth knowledge of bfd and is interested in this issue exists. FWIW, as I wrote previously, the difficulties I would anticipate would be in the direction of size differences in the thread status information etc., rather than using bfd to write the memory image. > I also found out, and found a mailing list post that confirmed, that gdb gcore > also does not work to generate a core image on Windows, as that was my next > place to look. Again, there's no such thing as a "Windows core file" (*) There's this special thing that Cygwin's dumper writes which is an ELF container for the process memory image, with NT_WIN32PSTATUS ELF notes which contain Win32 API thread status structures. (*) well, there are Windows minidumps, and it would perhaps be conceptually simpler if this was implemented using those, but getting gdb to read those would be a major project. > So it looks like gdb gcore for x86 could be implemented by adding the dumper code. Yes. I'm not sure that adds a huge amount of value, though, as we already have a working dumper for x86. > The question is where to ask or look to figure out what Windows x86_64 needs > over what Windows x86 needs, and add that to both gdb gcore and dumper, as gdb > seems to handle debugging and debuginfo fine. You can ask here, or on the cygwin-developers list, or on IRC. But if you're just asking questions, with no intention of actually doing the work, that would just be a waste of everyone's time. :) I'd suggest you start by looking at elfcore_grok_win32pstatus() in libbfd, and comparing that with the ELF notes that dumper.cc writes, also specifically looking for assumptions about sizes which might be different for x86 and x86_64. Next you'd want to look at i386-cygwin-tdep.c in gdb, and how that handles the '.reg' and '.module' pseudo-sections that are created by that when reading the core dump. > If this could be derived from say, Cygwin ld libbfd calls, or the diffs between > x86 and x86_64 ld.bfd calls, or nm, objcopy, objdump etc. diffs, I could look at > doing that. > I'm not sure I'd want to have to understand in detail how Windows puts its exes > together to get started. I don't think any knowledge of PE/COFF executables is needed to do this work (since, again, the "core dump" uses a ELF container). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple