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 Date: Sun, 9 May 1999 15:54:36 +0400 From: Egor Duda X-Mailer: The Bat! (v1.029) S/N A0F2A05A Reply-To: Egor Duda Organization: DEO Message-ID: <15662.990509@logos-m.ru> To: cygwin-developers CC: Chris Faylor Subject: Re: new core files Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Saturday, May 08 1999, Chris Faylor wrote to Egor Duda: [skipped...] >> 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. CF> I'm not sure why you're writing symbol information. That shouldn't be CF> necessary. Symbol information should come from the DLL itself. Also, CF> there is no reason to write out the text segment since that should CF> also be coming from the DLL also. The problem is to tell debug info from data segment by looking into process's virtual memory. The only way i know is to try to find out full path to dll or exe, which is mapped into given part of process's address space, and to extract segment info from the image. But the only "legal" way to do it, afaik, is to use microsoft's nt-only psapi.dll. CF> I believe that the only thing that should show up in a core file is CF> the stack, the heap, the data segments of the program and any DLLs (or CF> at least the cygwin DLL) and register contents. Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19