Date: Mon, 19 Jun 2006 18:20:54 -0400 (EDT) From: "Andrew R. Reiter" <arr@watson.org> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, current@freebsd.org Subject: Re: NULL pointer dereference panic Message-ID: <20060619181929.W40529@fledge.watson.org> In-Reply-To: <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> <20060619221550.GM23729@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Jun 2006, Yar Tikhiy wrote:
: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.
:
Thanks for the information regarding athlon-xp. Have other OSes done
anything (special casing?) for this hardware so as to make it more easy
for "better" traces to be done?
Thanks for any info.
Cheers,
Andrew
--
arr@watson.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060619181929.W40529>