> I've been staring at kernel code, and at a kernel crash dump, and I
> see a *very* wierd behavior.  Either gdb is lying to me, or there is
> a cache (or something!) playing games with what I got in the crash
> dump.

> First, the most recent traceback:  [...]

> malloc is called with "flags" = 0.  [M_WAITOK]

> later, in malloc, kmem_malloc is called with "canwait" set to zero.
> However, the code that does this reads as follows:

> va = (caddr_t) kmem_malloc(kmem_map, (vm_size_t)ctob(npg),
>                                            !(flags & M_NOWAIT));

Presumably the first two statements about what is called with what
arguments really mean that that's what the stack trace prints.

What is going on here is almost certainly that the kernel was compiled
with optimization turned on, and gcc determined that (for example) the
flags argument to malloc is dead after the third argument to
kmem_malloc is computed, so it reuses that register for some temporary
value.  The stack trace finds that temporary value there and dutifully
prints it out.  I've seen this happen in userland code; there's no
reason it couldn't happen in the kernel too.  gdb sees the debugging
info saying that argument such-and-such is in register so-and-so, but
there's no way for the compiler to tell gdb that as of some point in
the code, the argument is dead and the register got reused.

Of course, this may not explain everything, but it could be part of the
weirdness you're seeing.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B