assert creates unusable core dump on current stable Cygwin release
Jon Turney
jon.turney@dronecode.org.uk
Sun Oct 13 16:27:00 GMT 2019
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
More information about the Cygwin
mailing list