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:reply-to:subject:to:references:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=wohDhkYv4uk3Qr6/
	+wH9f1PTt2Ex2CesAbsi0fFh1jIiLUo9RJmI4owVX44+8JHQHA3+loN8SaKNEKqt
	1Nu/m9u3Zqw26GcirR1ZvzKe6qnFoAz1qPgrbVZP3ELcPcjgN0eb8sYbjPwI+Dic
	0MyE8cLVVuu0Qy9KFrMu88xT7Uo=
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:reply-to:subject:to:references:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=Pt02dLRj3cdRvCms2zNB3O
	wm0Cs=; b=WeROFNAKwp99HHjNHWJDQFkJTE+lpH4ZQNqClMYHWwYOZvQ8ar64iw
	GLmsnERsr8bFGNYbQeiqIDqMIQteuTfDPX4BnauC4nui3FsoRCIo0X1RZZvH+SHO
	kbPirVfzNm/cSR0ks4d19R5Fo+fkn0E89ypq5807OUJ0hRLB76cf8=
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=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=commitments, disturbing, discretion, calgary
X-HELO: smtp-out-so.shaw.ca
Reply-To: Brian DOT Inglis AT SystematicSw DOT ab DOT ca
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> <244f3cd4-59b5-e28a-cd9c-e23f6c259f59 AT dronecode DOT org DOT uk>
From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Openpgp: preference=signencrypt
Message-ID: <d4a7b85c-d49f-e669-3c7d-8d330d6815f7@SystematicSw.ab.ca>
Date: Sun, 13 Oct 2019 12:14:04 -0600
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: <244f3cd4-59b5-e28a-cd9c-e23f6c259f59@dronecode.org.uk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes

On 2019-10-13 10:27, Jon Turney wrote:
> 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.

Yes, but we don't have that yet in GDB, although GDB understands both x86 and
x86_64 in memory exe formats, so if we added gcore to x86 GDB, we should be able
to adapt that for x86_64, then apply analogous x86_64 dumper changes based on
the gcore changes, as presumably they are all based around libbfd.

>> 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. :)

We're in a catch-22, as we need enough info to think the work can be completed
successfully with a reasonable amount of effort and time.
I've wasted time before doing bunches of R never getting to D! ;^>
My concerns are around hearing that Win64 exes are a totally different format in
a PE wrapper; on the other hand, Cygwin GDB can load, run, debug them okay, so
libbfd must work somewhat compatibly, but if it was easy, it would have been
done, so we need some basis for how to do it and how long it will take.

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

Thanks, will look at GDB, binutils, libbfd, dumper, and arch source differences
late next week, as I have some commitments.
Any idea why libbfd is not a separate package under Cygwin, like other distros,
but presumably part of both binutils and gdb?

>> 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).

But presumably that PE/COFF in-memory executable format has to be picked apart,
and that has already been done to allow GDB to work with it, then written into
that ELF container, and that part has not been done yet, so should be less than
trivial or blindingly obvious.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

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