This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: Cygwin 1.3.3, dumper.exe, question
- To: Christopher Faylor <cygwin-developers at cygwin dot com>
- Subject: Re: Cygwin 1.3.3, dumper.exe, question
- From: egor duda <deo at logos-m dot ru>
- Date: Sat, 8 Sep 2001 17:11:16 +0400
- Organization: deo
- References: <20010906214242.A24962@redhat.com>
- Reply-To: egor duda <cygwin-developers at cygwin dot com>
Hi!
Friday, 07 September, 2001 Christopher Faylor cgf@redhat.com wrote:
CF> I'm going to be including dumper.exe with the next version of cygwin.
CF> I've been meaning to do this for a long time and I keep forgetting.
CF> I'm going to mention this in the release notes:
CF> - dumper.exe now comes with cygwin releases by default. With dumper.exe
CF> you can actually have linux produce linux-style core dumps. To use,
CF> set CYGWIN=error_start=c:/cygwin/bin/dumper.cmd
CF> Then if you cygwin application enters into a state where a core dump
CF> would be produced under linux (e.g., SIGSEGV, SIGBUS, etc.) dumper.exe
CF> will be called to produce it. You can then use gdb to inspect the
CF> Does this seem correct? I will include a dumper.cmd file which just
CF> has this in it:
CF> dumper -c %1 %2
CF> However wouldn't it make sense for dumper to take the same arguments as
CF> gdb? If there are two arguments then the first is a filename and the
CF> second is a pid.
CF> Then I wouldn't need to create a dumper.cmd file.
i've got no objections to this. i've patched dumper sources in my
local tree to avoid the need to '-c', if nobody's against it, i'll
check it in.
CF> Egor? I have a feeling this has been discussed before. I should probably
CF> check the archives but that would set a bad precedent...
no, i don't remember it's being discussed :)
Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19