From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14590 invoked by alias); 11 Jun 2002 18:09:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14572 invoked from network); 11 Jun 2002 18:09:22 -0000 Received: from unknown (HELO MAIL.leftcoast.net) (204.50.27.10) by sources.redhat.com with SMTP; 11 Jun 2002 18:09:22 -0000 Received: from [66.122.53.111] by MAIL.movieeditor.com (NTMail 7.02.3037/NT1366.01.4e6cd0bc) with ESMTP id qhvkghaa for gdb@sources.redhat.com; Tue, 11 Jun 2002 11:09:57 -0700 Message-ID: <003301c21173$1ff4bfc0$0301a8c0@rowboat> From: "Robin Rowe" To: Subject: JIT Debugging Documentation Date: Tue, 11 Jun 2002 11:09:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SW-Source: 2002-06/txt/msg00090.txt.bz2 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. ###