From owner-freebsd-arch@FreeBSD.ORG Mon Jul 4 23:14:02 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5325716A41C for ; Mon, 4 Jul 2005 23:14:02 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0D6643D46 for ; Mon, 4 Jul 2005 23:14:01 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Jul 2005 19:14:00 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 3D2B613643; Mon, 4 Jul 2005 19:14:00 -0400 (EDT) Date: Mon, 4 Jul 2005 19:14:00 -0400 From: Ed Maste To: Peter Wemm Message-ID: <20050704231359.GA58430@sandvine.com> References: <20050623102024.GA89874@frontfree.net> <200506231815.44052.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506231815.44052.peter@wemm.org> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 04 Jul 2005 23:14:00.0493 (UTC) FILETIME=[0FC2E5D0:01C580EE] Cc: freebsd-arch@freebsd.org Subject: Re: How to get stack from every thread when doing crash dump? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2005 23:14:02 -0000 On Thu, Jun 23, 2005 at 06:15:43PM -0700, Peter Wemm wrote: > But I wonder if what you're running into is possibly a result of gdb not > parsing the stack frames from exception.s? We do not emit any dwarf2 > call frame information for any assembler code, and gdb6 is dwarf2 > based. And since it is dwarf2 based, during the last cleanups the gdb > developers did, they removed (or moved) the places that we used to > insert stack frame sniffers to cope with crossing the nonstandard > assembler stack frames. As a result, we don't generally show traces > that cross exceptions any more. It seems worse than that -- the gdb backtrace might show unknown or completely bogus frames as a result. For example, we've run across the tty locking issue (discussed on -stable), and backtraces often look like: #6 0xa0723d8a in calltrap () at /usr/src/sys/i386/i386/exception.s:202 #7 0xc7f10018 in ?? () #8 0xa05b0010 in power_profile_set_state (state=0) at /usr/src/sys/kern/subr_power.c:110 #9 0xa05c942c in ttwakeup (tp=0xa23fdc00) at /usr/src/sys/kern/tty.c:2370 #10 0xa05c7d71 in ttymodem (tp=0xa23fdc00, flag=0) at /usr/src/sys/kern/tty.c:1625 when in reality frames 7 and 8 should actually be a single frame in knote(). > If that is the problem you're seeing, then the fix is that somebody > needs to annotate the *.s and *.S files with .cfa_* pseudo-ops so that > dwarf2 frame descriptors are emitted for a -g kernel. This is > non-trivial though. I assume you meant .cfi_* -- .cfi_startproc, .cfi_offset etc? I had a quick look and it doesn't seem like it should be difficult. I ran into one issue though -- these get written to the .eh_frame section. The data emitted by gcc goes in .debug_frame, but the two have the same format. I tried changing the linker script to put both in the .debug_frame section, but ld faild ("Not enough room for program headers"). The .eh_frame section is marked loadable, so it seems ld still tries to create a phdr entry for it. Once I can figure out how to address that I'll test out adding the .cfi_ pseudo-ops to exception.s. -- Ed Maste, Sandvine Incorporated