This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: assert creates unusable core dump on current stable Cygwin release
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