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: Sat, 8 May 1999 19:48:21 +0400 From: Egor Duda X-Mailer: The Bat! (v1.029) S/N A0F2A05A Reply-To: Egor Duda Organization: DEO Message-ID: <13825.990508@logos-m.ru> To: cygwin-developers Subject: new core files Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! 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? 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. 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? Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19