Re: assert creates unusable core dump on current stable Cygwin release

[Jon Turney <jon.turney@dronecode.org.uk>]

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