Is corefile support for missing on Win32?

Is corefile support for missing on Win32?

[Simon Sobisch]

Testing with MSYS2 generated mingw64 gcc 12.1 + gdb 12.1 resulted in 
"everything working" ...until I needed to create a core file.

(gdb) show arch
The target architecture is set to "auto" (currently "i386:x86-64").
(gdb) gcore test.core
warning: cannot close "test.core": invalid operation
Can't create a corefile

(with gnutarget auto, pei-x86-64 and pe-x86-64)

I see that the first error message comes from
   gdb/gdb_bfd.c (gdb_bfd_close_warning)
and the second from the default implementation
   gdb/exec.c (make_corefile_notes)


This issue seems to exists for longer as some SO question [1] asked 
about this over 5 years ago.

Further testing showed the same issue with same tools in MinGW x86 and 
with "good old MinGW" using GDB 7.6.1 / GCC 9.2.

Testing with cygwin-x64 (GDB 11.2) shows the same result.


Questions:

* Is there something missing in the configuration / build to get it working?
* Should I file a bug on 
https://sourceware.org/bugzilla/buglist.cgi?component=corefiles ?

Thanks to share some info,
Simon


Background: I want to move from an "unsafe signal handler" doing a 
text-dump of variables in GnuCOBOL to "create a coredump, let the user 
inspect this"; but if this doesn't work on Win32 I may need some 
different approach there.

I guess the system's minidump format cannot be processed with GDB, can it?

Do you see other options to do post-mortem debugging on Win32?

Simon


[1]:https://stackoverflow.com/questions/41468614/warning-cannot-close-core-xxxxx-invalid-operation

Re: Is corefile support for missing on Win32?

[Pedro Alves]

On 2022-06-07 20:30, Simon Sobisch via Gdb wrote:
> Testing with MSYS2 generated mingw64 gcc 12.1 + gdb 12.1 resulted in "everything working" ...until I needed to create a core file.
> 
> (gdb) show arch
> The target architecture is set to "auto" (currently "i386:x86-64").
> (gdb) gcore test.core
> warning: cannot close "test.core": invalid operation
> Can't create a corefile
> 
> (with gnutarget auto, pei-x86-64 and pe-x86-64)
> 
> I see that the first error message comes from
>   gdb/gdb_bfd.c (gdb_bfd_close_warning)
> and the second from the default implementation
>   gdb/exec.c (make_corefile_notes)
> 
> 
> This issue seems to exists for longer as some SO question [1] asked about this over 5 years ago.
> 
> Further testing showed the same issue with same tools in MinGW x86 and with "good old MinGW" using GDB 7.6.1 / GCC 9.2.
> 
> Testing with cygwin-x64 (GDB 11.2) shows the same result.
> 

Native Windows GDB was never able to generate cores.  Basically because cores are ELF objects,
while Windows is PE, so it's kind of a foreign thing.

However, Cygwin comes with a separate utility that is able to dump cores in ELF format, and
Windows GDB is actually able to read those.  This utility is called "dumper".  See here:

  https://www.cygwin.com/cygwin-ug-net/dumper.html

Sources are here:

  https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/utils/dumper.cc

If someone wanted to work on it, I don't see any obstacle to GDB's gcore command
itself generating an ELF core in the exact same format.

> I guess the system's minidump format cannot be processed with GDB, can it?

Unfortunately not.  Christian Biesinger did write a patch to add support for it while ago, though:

  https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/cbiesinger/minidump

AFAIK, this was never finished/contributed for proper inclusion, and I don't know how far
that is to being complete.

Re: Is corefile support for missing on Win32?

[Simon Sobisch]

This is especially a call to Christian Biesinger to ask if there was any 
more work on "supporting minidump with GDB"; but there's more content 
"inline" in the text, too.


Am 09.06.2022 um 18:20 schrieb Pedro Alves:
> On 2022-06-07 20:30, Simon Sobisch via Gdb wrote:
>> Testing with MSYS2 generated mingw64 gcc 12.1 + gdb 12.1 resulted in "everything working" ...until I needed to create a core file.
>>
>> (gdb) show arch
>> The target architecture is set to "auto" (currently "i386:x86-64").
>> (gdb) gcore test.core
>> warning: cannot close "test.core": invalid operation
>> Can't create a corefile
>>
>> (with gnutarget auto, pei-x86-64 and pe-x86-64)
>>
>> I see that the first error message comes from
>>    gdb/gdb_bfd.c (gdb_bfd_close_warning)
>> and the second from the default implementation
>>    gdb/exec.c (make_corefile_notes)
>>
>>
>> This issue seems to exists for longer as some SO question [1] asked about this over 5 years ago.
>>
>> Further testing showed the same issue with same tools in MinGW x86 and with "good old MinGW" using GDB 7.6.1 / GCC 9.2.
>>
>> Testing with cygwin-x64 (GDB 11.2) shows the same result.
>>
> 
> Native Windows GDB was never able to generate cores.  Basically because cores are ELF objects,
> while Windows is PE, so it's kind of a foreign thing.

I see. That's a real pitty, but maybe this improves some day.

> However, Cygwin comes with a separate utility that is able to dump cores in ELF format, and
> Windows GDB is actually able to read those.  This utility is called "dumper".  See here:
> 
>    https://www.cygwin.com/cygwin-ug-net/dumper.html
> 
> Sources are here:
> 
>    https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/utils/dumper.cc
> 
> If someone wanted to work on it, I don't see any obstacle to GDB's gcore command
> itself generating an ELF core in the exact same format.

That would be an interesting point I'll check with its contributors later.

In the meantime I did test the dumper on cygwin, it works there but only 
in specific cases (I did not get it to work in mot cases "while the 
process runs", as it often generates a file that contains only threads 
in the Windows API where no debugging symbols are available and 
therefore all threads have broken backtraces with not a single one in 
the program space one is interested in.
This _may_ worked around if the generation could be postponed until the 
code reaches "program space", but I don't know enough about that (and it 
won't work on a "real abort".
Note: the part where it _did_ work was when "dumper" is hooked into 
cygwin's internal abort handling, then reaching a SIGSEGV.
The corefile was not usable when, for example, the user code did `raise(6)`.

>> I guess the system's minidump format cannot be processed with GDB, can it?
> 
> Unfortunately not.  Christian Biesinger did write a patch to add support for it while ago, though:
> 
>    https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/cbiesinger/minidump
> 
> AFAIK, this was never finished/contributed for proper inclusion, and I don't know how far
> that is to being complete.

We'll see if/how Christian (or others that now about that approach from 
2020) answers.

Thanks for any hints,
Simon

Re: Is corefile support for missing on Win32?

[Christian Biesinger]

On Tue, Feb 7, 2023 at 5:36 AM Simon Sobisch <simonsobisch@gnu.org> wrote:
>
> This is especially a call to Christian Biesinger to ask if there was any
> more work on "supporting minidump with GDB"; but there's more content
> "inline" in the text, too.

Yes unfortunately I have not continued work on that branch. It is more
of a proof of concept at this point, most types of data are not
implemented yet, outside of registers and memory.

I also did not love the way I integrated minidump support with the
rest of GDB. It was done as a new BFD target and converted minidump
info to ELF coredump-style in-memory sections. That's fine for memory
but feels awkward for register data... and possibly requires special
code for each arch/OS combination (e.g. amd64_linux_gregset_reg_offset
may be different from the Windows and Mac equivalent, and of course is
different from x86 and ARM)

I haven't looked into mapping loaded DLLs and threads.

Realistically this will need someone else to pick up this work, unless
I unexpectedly find myself with a large amount of free time.

(Obviously this does not support PDB debug symbols, another project
that would be interesting to do. Perhaps it could use the Python
symbol support for which I saw patches go by the other week)

In the meantime you may be interested in this tool:
https://chromium.googlesource.com/chromium/src.git/+/main/docs/linux/minidump_to_core.md

Christian

>
>
> Am 09.06.2022 um 18:20 schrieb Pedro Alves:
> > On 2022-06-07 20:30, Simon Sobisch via Gdb wrote:
> >> Testing with MSYS2 generated mingw64 gcc 12.1 + gdb 12.1 resulted in "everything working" ...until I needed to create a core file.
> >>
> >> (gdb) show arch
> >> The target architecture is set to "auto" (currently "i386:x86-64").
> >> (gdb) gcore test.core
> >> warning: cannot close "test.core": invalid operation
> >> Can't create a corefile
> >>
> >> (with gnutarget auto, pei-x86-64 and pe-x86-64)
> >>
> >> I see that the first error message comes from
> >>    gdb/gdb_bfd.c (gdb_bfd_close_warning)
> >> and the second from the default implementation
> >>    gdb/exec.c (make_corefile_notes)
> >>
> >>
> >> This issue seems to exists for longer as some SO question [1] asked about this over 5 years ago.
> >>
> >> Further testing showed the same issue with same tools in MinGW x86 and with "good old MinGW" using GDB 7.6.1 / GCC 9.2.
> >>
> >> Testing with cygwin-x64 (GDB 11.2) shows the same result.
> >>
> >
> > Native Windows GDB was never able to generate cores.  Basically because cores are ELF objects,
> > while Windows is PE, so it's kind of a foreign thing.
>
> I see. That's a real pitty, but maybe this improves some day.
>
> > However, Cygwin comes with a separate utility that is able to dump cores in ELF format, and
> > Windows GDB is actually able to read those.  This utility is called "dumper".  See here:
> >
> >    https://www.cygwin.com/cygwin-ug-net/dumper.html
> >
> > Sources are here:
> >
> >    https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/utils/dumper.cc
> >
> > If someone wanted to work on it, I don't see any obstacle to GDB's gcore command
> > itself generating an ELF core in the exact same format.
>
> That would be an interesting point I'll check with its contributors later.
>
> In the meantime I did test the dumper on cygwin, it works there but only
> in specific cases (I did not get it to work in mot cases "while the
> process runs", as it often generates a file that contains only threads
> in the Windows API where no debugging symbols are available and
> therefore all threads have broken backtraces with not a single one in
> the program space one is interested in.
> This _may_ worked around if the generation could be postponed until the
> code reaches "program space", but I don't know enough about that (and it
> won't work on a "real abort".
> Note: the part where it _did_ work was when "dumper" is hooked into
> cygwin's internal abort handling, then reaching a SIGSEGV.
> The corefile was not usable when, for example, the user code did `raise(6)`.
>
> >> I guess the system's minidump format cannot be processed with GDB, can it?
> >
> > Unfortunately not.  Christian Biesinger did write a patch to add support for it while ago, though:
> >
> >    https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/cbiesinger/minidump
> >
> > AFAIK, this was never finished/contributed for proper inclusion, and I don't know how far
> > that is to being complete.
>
> We'll see if/how Christian (or others that now about that approach from
> 2020) answers.
>
> Thanks for any hints,
> Simon

Re: Is corefile support for missing on Win32?

[Hannes Domani]

 Am Dienstag, 7. Februar 2023, 21:19:29 MEZ hat Christian Biesinger via Gdb <gdb@sourceware.org> Folgendes geschrieben:

> On Tue, Feb 7, 2023 at 5:36 AM Simon Sobisch <simonsobisch@gnu.org> wrote:
> >
> > This is especially a call to Christian Biesinger to ask if there was any
> > more work on "supporting minidump with GDB"; but there's more content
> > "inline" in the text, too.
>
> Yes unfortunately I have not continued work on that branch. It is more
> of a proof of concept at this point, most types of data are not
> implemented yet, outside of registers and memory.
>
> I also did not love the way I integrated minidump support with the
> rest of GDB. It was done as a new BFD target and converted minidump
> info to ELF coredump-style in-memory sections. That's fine for memory
> but feels awkward for register data... and possibly requires special
> code for each arch/OS combination (e.g. amd64_linux_gregset_reg_offset
> may be different from the Windows and Mac equivalent, and of course is
> different from x86 and ARM)
>
> I haven't looked into mapping loaded DLLs and threads.
>
> Realistically this will need someone else to pick up this work, unless
> I unexpectedly find myself with a large amount of free time.
>
> (Obviously this does not support PDB debug symbols, another project
> that would be interesting to do. Perhaps it could use the Python
> symbol support for which I saw patches go by the other week)
>
> In the meantime you may be interested in this tool:
> https://chromium.googlesource.com/chromium/src.git/+/main/docs/linux/minidump_to_core.md

I implemented minidump support for gdb some time ago.

The main commits are these:
https://github.com/ssbssa/gdb/compare/b4535a016c98a5a15622bbdcbcd845e3387413f5...8961acde2b6521f629ddaa1880ba312b998351eb

Since I didn't know any better, I just put the code into coffgen.c, which
was probably not a good idea.

You can try it out with my builds here:
 https://github.com/ssbssa/gdb/releases


Regards
Hannes