From: "Robin Rowe" <rower@MovieEditor.com>
To: <gdb@sources.redhat.com>
Subject: JIT Debugging Documentation
Date: Tue, 11 Jun 2002 11:09:00 -0000 [thread overview]
Message-ID: <003301c21173$1ff4bfc0$0301a8c0@rowboat> (raw)
Below is my documentation draft of JIT Debugging and Core Dumps. I searched
in the gdb documentation, but was unable to discover the name of the gdb
docs maintainer. Who is responsible for updating the docs?
Cheers,
Robin
---------------------------------------------------------------------------
www.OpenSourceProgrammers.org
www.LinuxMovies.org
JIT Debugging
Just-In-Time debugging is a feature some debuggers use to automatically load
a crashing program at the moment of death, even though the program wasn't
started in the debugger. FYI, in Windows programs it is possible to
deliberately activate the debugger, perhaps in reaction to a failed
assertion, by calling interrupt 3 in inline assembly.
1. For Linux systems there is no JIT debugging feature, but Michael Sinz
notes some progress implementing this feature as of June 10, 2002. He says
it isn't a priority.
2. To enable JIT debugging under Windows cygwin add
"error_start=c:\path\to\gdb\gdb.exe" to the CYGWIN environment variable.
When a program faults gdb will be automatically invoked and attach to the
crashed process.
Core Dumps
A core dump is a snapshot of a program's memory at the moment it crashed.
Using gdb you can then analyze the core dump file to help discover what went
wrong with the program. The first thing you would typically check in a core
file is the stack trace to see what function the failure occured in.
1. To enable core dumps in Linux set ulimit. Core dumps are always named
"core". However, Michael Sinz submitted a patch to the linux-kernel list on
Feb. 14, 2002, to enable specifying where core dumps are stored and what the
name of the core dump is. (This enables collecting cores from clusters or
network workgroups.)
2. To enable core dumps in Windows cygwin build dumper.exe from cygwin cvs.
Add "error_start=c:\path\to\dumper\utility\dumper.exe" to the CYGWIN
environment variable. A program fault will generate a core named
"crashed-program.exe.core." The core file can be analyzed with
"gdb --core=crashed-program.exe.core". You may need latest sources of gdb,
bfd, and cygwin from sourceware cvs to do this.
###
next reply other threads:[~2002-06-11 18:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-11 11:09 Robin Rowe [this message]
2002-06-12 3:58 ` egor duda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='003301c21173$1ff4bfc0$0301a8c0@rowboat' \
--to=rower@movieeditor.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox