Re: NULL pointer dereference panic

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