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: Tue, 11 May 1999 10:52:44 +0400
From: Egor Duda <deo AT logos-m DOT ru>
X-Mailer: The Bat! (v1.029) S/N A0F2A05A
Reply-To: Egor Duda <deo AT logos-m DOT ru>
Organization: DEO
Message-ID: <5453.990511@logos-m.ru>
To: Mikey <jeffdb AT goodnet DOT com>,
        cygwin-developers <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Re[2]: new core files
References: <37373761 DOT 753883 AT mail DOT goodnet DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

May 10 1999 Mickey <jeffdbREMOVETHIS AT goodnet DOT com> wrote:

M> The reason that win32 doesn't support core dumps
M> is that it supports JIT debugging.

M> Wouldn't it be more appropriate for this platform
M> to get gdb.exe to work correctly with JIT than
M> to clutter up everyones disks with a bunch of
M> core files that most people would have no
M> idea how to use, or why they are getting them?

I've already posted a patch to allow JIT debugging of cygwin apps with
gdb. Core files are good to find out why in hell one of your daemons
crashed at 03:00am and dragged all your system down at 03:05am.
Actually, i intend to add support for jit debugging and core dumping
in a uniform way. You would just specify through %CYGWIN% a program to
run in a case of trap and application will try to start it (passing
some   info   about   itself).   Will   this   program  be  gdb(jit),
core-dumper(post-mortem), something else or nothing -- it's up to you.

M> For sure there needs to be an on/off setting in %CYGWIN%
M> that defaults to OFF.

surely.

M> I confess I took a hack at this myself (JIT), and couldn't
M> get anywhere, but the docs are there on the msdn.

M> It almost looks like you need to use 2 threads,
M> one to accept the initial debug events,
M> (create process/thread load dll)
M> which then exits allowing the system to send out the
M> AED debug event and another (the main gdb thread)
M> to attach to and actually control the app.

there's no need in it. Gdb itself is pretty good in attaching to
existing process and debugging it. The only drawback i've encountered
is that he cannot determine full names of dll's, loaded by debugee,
and extract debug info from them. you should either "add-symbol-file"
for all those dll's manually or apply a patch to gdb (alas, it works on
nt only and uses psapi.dll from ResKit).

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19