Mail Archives: cygwin-developers/1999/05/11/02:55:48
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
- Raw text -