X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:subject:to:references:cc:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=UPvrH/mdsNnLQzCa
	oJcJyqmT+mCbq4l94lI6ZHQxh7pmsllW1ikfOOTn7BCNYtJQzY5KV4N5G+n89yIe
	ZT3r7jL/hE1v3vZZk95Z/D1+XlTJn1MHm+GInygYxTrIUg1i0TxKFp0yjYqdupFG
	p++BSaShbBgsmeZ9cGbM70dKiLU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:subject:to:references:cc:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=vtIpl/f5cTVzGQ7WjIFDhH
	jjqw8=; b=ZYF4MtGqPAwu+tOyI1n+lF3dydd1Sflf1fQ50qII9opIS2rZJzOCor
	L68cQH466js1Ux/B/NWpwf0+itlhvNAlkF4GzEX+gUEhbupwM6+Oc7ltiTt/p+Jc
	+p31wU2AOF7KIFnKLROVTf9jSWwzgaLWcfbM7z1y2z/qzyPb1Xr3o=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
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
Authentication-Results: btinternet.com;    auth=pass (PLAIN) smtp.auth=jonturney AT btinternet DOT com
X-OWM-Source-IP: 86.141.128.155 (GB)
X-OWM-Env-Sender: jonturney AT btinternet DOT com
X-VadeSecure-score: verdict=clean score=0/300, class=clean
From: Jon Turney <jon DOT turney AT dronecode DOT org DOT uk>
Subject: Re: assert creates unusable core dump on current stable Cygwin release
To: The Cygwin Mailing List <cygwin AT cygwin DOT com>
References: <CALK-3mJyg6pox9a+ZNgGmspcxBFcgGJ3XymXAOOPP6_Z_tSUjQ AT mail DOT gmail DOT com> <2300fe24-fc50-3d1c-6b1b-bf6da6022d2e AT SystematicSw DOT ab DOT ca> <b8379f49-3e22-23c8-80d9-d18f45e10a42 AT dronecode DOT org DOT uk> <71be3508-b11e-4681-eac6-9d44845088c7 AT SystematicSw DOT ab DOT ca> <1ac90af2-412d-345f-da40-8260ae527096 AT dronecode DOT org DOT uk> <CAEhDDbB6WRfph6+TRUgCpPiorTodozfe26GmmqOWjM2vieZn+w AT mail DOT gmail DOT com> <380e89cb-4e31-4af2-40ca-c143e6622424 AT SystematicSw DOT ab DOT ca>
Cc: Brian DOT Inglis AT SystematicSw DOT ab DOT ca
Message-ID: <244f3cd4-59b5-e28a-cd9c-e23f6c259f59@dronecode.org.uk>
Date: Sun, 13 Oct 2019 17:27:15 +0100
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

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