From owner-freebsd-current@FreeBSD.ORG Mon Jun 19 22:15:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B22E816A474 for ; Mon, 19 Jun 2006 22:15:59 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 675CF43D48 for ; Mon, 19 Jun 2006 22:15:56 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k5JMFpY9028669; Tue, 20 Jun 2006 02:15:51 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k5JMFpIK028664; Tue, 20 Jun 2006 02:15:51 +0400 (MSD) (envelope-from yar) Date: Tue, 20 Jun 2006 02:15:50 +0400 From: Yar Tikhiy To: Peter Jeremy Message-ID: <20060619221550.GM23729@comp.chem.msu.su> References: <20060618192011.GF715@turion.vk2pj.dyndns.org> <20060618152428.A36995@fledge.watson.org> <20060619184540.GJ23729@comp.chem.msu.su> <20060619190822.GE966@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060619190822.GE966@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.5.9i Cc: current@freebsd.org Subject: Re: NULL pointer dereference panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 22:15:59 -0000 On Tue, Jun 20, 2006 at 05:08:22AM +1000, Peter Jeremy wrote: > On Mon, 2006-Jun-19 22:45:41 +0400, Yar Tikhiy wrote: > >Peter, what gcc options did you build the kernel with? My question > >is unrelated to the panic, I'd just like to make stack traces look > >sane in common cases :-) > > In /etc/make.conf: > CPUTYPE?=athlon-xp > CFLAGS=-O -pipe > COPTFLAGS=-O -pipe Indeed, gcc in athlon-xp mode handles function calls in a manner different from the i386 default one. The old backtrace would be confused, too, by the code generated so. Technical details for curious folks: When in basic i386 mode, gcc calls functions in the traditional way. E.g., the "foo(1, 2)" call will look as follows in asm: pushl $2 pushl $1 call foo addl $8, %esp By merely decoding the addl instruction at the return pointer we can find how many words of arguments the called function takes. In the example, it takes 8 / 4 = 2 words, where 4 is the size of a machine word. In athlon-xp mode, the parent function reserves once, at its prologue, stack space enough for the arguments to any of its child functions. Then the same "foo(1, 2)" call is made in a "RISCy" way: movl $2, 0x4(%esp) movl $1, (%esp) call foo Since the stack pointer no longer needs to be adjusted after each call, we cannot guess the number of arguments by decoding the instruction at the return address. The fdrop() call is a case of particular confusion. The C source essentially reads: closef() { ... return (fdrop(...)); } In athlon-xp mode, it becomes: call fdrop addl $0x6c, %esp pop %ebx leave ret The addl there is not to adjust the stack after the call to fdrop(), it's the epilogue of closef() freeing the space reserved for local vars and child function arguments. Alas, we cannot tell it from addl in the traditional case, as though fdrop() took 27 words of arguments. -- Yar