From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5825 invoked by alias); 24 Jul 2002 16:47:07 -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 5818 invoked from network); 24 Jul 2002 16:47:06 -0000 Received: from unknown (HELO racerx.ixiacom.com) (64.60.75.69) by sources.redhat.com with SMTP; 24 Jul 2002 16:47:06 -0000 Received: from ixiacom.com (dank.ixiacom.com [192.168.3.117]) by racerx.ixiacom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMBM6XFS; Wed, 24 Jul 2002 09:45:03 -0700 Message-ID: <3D3EE3D4.9030502@ixiacom.com> Date: Wed, 24 Jul 2002 09:47:00 -0000 From: Dan Kegel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3 MIME-Version: 1.0 To: Daniel Jacobowitz CC: Lucy Zhang , gdb@sources.redhat.com Subject: Re: Thread signal information References: <004501ea8fb2$e33da4c0$9a0a0109@zhangl> <20020724160422.GA5346@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00250.txt.bz2 Daniel Jacobowitz wrote: > On Wed, Jul 24, 2002 at 09:00:43AM -0700, Lucy Zhang wrote: >>I'm constructing an ELF core dump (conversion from a different formatted >>dump). I'm trying to add thread information by using a prstatus struct for >>each thread. I was wondering what should I put for the signal information >>for each thread. Do I even need this info for threads other than the >>faulting thread? > > Not really. I believe that GDB only recognizes the signal in the first > listed thread (or it may have been the last listed thread.... there was > a fix in this area recently, I believe). First listed (faulting) > certainly makes the most sense, and GDB definitely only cares about one > thread. Does one give up anything by doing a postmortem gdb session rather than a live session? Obviously one loses the ability to continue, but what else? Presumably (once we coax the OS into producing the proper core dump) we still can do 'info threads' and 'backtrace' on each thread, right? (I haven't used core dumps for a long, long time. Very recently, though, I used a signal handler to do just-in-time startup of gdbserver to help debug a program running on a 100 node cluster. If my nodes had hard disks, I'd be more likely to use coredumps :-) - Dan