Mailing-List:	contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin-developers AT sourceware DOT cygnus DOT com
From:	Chris Faylor <cgf AT cygnus DOT com>
Date:	Sat, 8 May 1999 16:06:27 -0400
To:	Egor Duda <deo AT logos-m DOT ru>
Cc:	cygwin-developers <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject:	Re: new core files
Message-ID:	<19990508160627.A672@cygnus.com>
References:	<13825 DOT 990508 AT logos-m DOT ru>
Mime-Version:	1.0
X-Mailer:	Mutt 0.95.3i
In-Reply-To:	<13825.990508@logos-m.ru>; from Egor Duda on Sat, May 08, 1999 at 07:48:21PM +0400

On Sat, May 08, 1999 at 07:48:21PM +0400, Egor Duda wrote:
>I've written a (prototype) code to allow cygwin programs dump "real"
>cores, and appropriate bfd back-end to make gdb understand them. And
>i've got a couple of questions. First -- whether trapped program
>should start separate process "a-la dr.Watson" to write core file, or
>it should write core file by itself? And second -- where should *.core
>go if current directory isn't writable?

It should definitely be a separate process.  Otherwise we're bloating
cygwin for the benefit of developers who want to look at core files.

>Now, all committed pages from process's virtual memory are dumped to
>core.  So dump of the minimal program takes 6-10M, depending of
>presence or absence of debug info in cygwin1.dll.  I feel that it's a
>bit overkill, but don't know common way to distinguish between "useful"
>pages and "void" ones.

I'm not sure why you're writing symbol information.  That shouldn't be
necessary.  Symbol information should come from the DLL itself.  Also,
there is no reason to write out the text segment since that should also
be coming from the DLL also.

I believe that the only thing that should show up in a core file is the
stack, the heap, the data segments of the program and any DLLs (or at
least the cygwin DLL) and register contents.

>Yet another problem is with gdb itself.  I've made it support new
>target "cygwin-core", but it still recognizes dump as coff :( Perhaps
>that's because dump contains parts of exe's image, which look pretty
>much like coff.  As a temporary workaround, I've set GNUTARGET env var
>to "cygwin-core", but i don't feel it's a proper way.  So would anybody
>kindly point me to the appropriate place in docs?

This is probably a question for the gdb AT sourceware DOT cygnus DOT com mailing list.
Somebody there should be able to help you.

I should point out that the subject of core dumps was recently raised in
some gdb discusions.  There seems to be a general consensus that for
targets, like cygwin, which don't support a native core dump format,
that the target should use the ELF core dump format.  It seems to be the
most flexible format for this type of thing.

-chris

- Raw text -