Re: [BProc] vmadump: mips port; apparenlt bug; etc

[Grant T. <gt...@sw...>]

>>>>> Erik Arjan Hendriks <er...@he...> writes:

> The alpha has the same problem.  See the big (and ugly) syscall entry
> code there for an example of what I did.  Basically the first bit of
> the syscall handler is a hunk of asm code that saves what doesn't
> normally get saved.  The alpha code is basically copied from context
> switch and fork.  It seems (from a glance at MIPS fork code) that this
> should be easily accomplished with the "save_static_function" macro.

Maybe.  But there are still registers not included in that or
SAVE_SOME.  As far as I can tell they're just saved and restored
ad-hoc by whatever functions run in the kernel, so the only place
they're easy to get at is when you're at the bottom of the stack about
to return from the syscall or context switch.

> It looks like FP will still be an issue on that platform.

This shouldn't matter for my application, where all freezes and thaws
are done in the middle of functions that have no fp.

FP doesn't work on this CPU, anyway.  I'd need to make the in-kernel
fp simulator dump state!

> Hrm.  Well, it works fine (and is required) on PPC.  I'm quite
> certain the icache flush functions take user addresses - see
> kernel/module.c and kernel/ptrace.c.  I'm basically doing the same
> thing there that module.c does to make the I and D caches
> consistent.  If I was flushing the wrong addresses, the PPC port
> should be broken too.

> Since it's blowing up only on SMP and (I presume) you can successfully
> load modules, I believe something else is wrong.

Well, I can buy that.  We use a static kernel; I have no idea if
module loading works.

The flush_icache_range() implementation is sb1_flush_icache_range() in
arch/mips/mm/sb1.c.  The comments there and in the other flush flavors
speak of Kseg0 addresses, which is what made me think it expected
non-userspace addresses.

Shouldn't calling flush_icache_page() on page table entries should do
the right thing either way?  Since doing this (or indeed, doing
flush_icache_all()) gives the symptoms of not flushing properly, and
flush_icache_range() panics on SMP, I'm beginning to wonder about the
platform icache flushing code.

Hmm...

> It's probably a waste of time.  GDB seems to get confused fairly
> easily when messing with weird stuff.

Or even with normal stuff.  GDB disassembles on our target at the rate
of one instruction every several seconds!

> Try takeing a closer look at how you're restoring the values that
> aren't saved in the default syscall entry.  The text switch back to
> user space needs to restore these values properly which means the
> return from syscall needs to do some magic there.  Failing to restore
> some of that will likely lead to a user space crash.  I saw that on
> alpha.

Yes, I got all this working flawlessly on uniprocessor by mangling all
the entry and exit points to do full saves and restores.  It's ugly
and inefficient, but until everything actually works this will have to
do.

--
Grant Taylor - x285 - http://pasta/~gtaylor/
Starent Networks - +1.978.851.1185