[Suspend2-devel] Bad EIP value
johannes at sipsolutions.net
Tue Jun 7 11:02:47 UTC 2005
Bernard Blackham said:
> In do_suspend2_lowlevel() we have:
> 1 move_stack_to_nonconflicing_area();
> 2 suspend2_copyback_low(); /* 0 = use logical addresses */
> 3 suspend2_restore_processor_context();
> 4 suspend2_flush_caches();
> 5 suspend2_copyback_high();
> 6 suspend2_flush_caches();
> 7 suspend2_post_copyback();
> 8 (restore loop and) suspend2_resume_2();
> We really only need suspend2_restore_processor_context to be
> inlined, as this is what restores our stack pointer so we return
> back into save_image().
> So if we make copyback_low noinline, and we pass everything else
> from 4-8 into a separate function that is declared noinline, then we
> can be certain that it won't touch the old stack, and we only need
> to worry about restore_processor_context().
> The critical point in restore_processor_context() is after restoring
> stack and frame pointer regs (then we can use our stack without
> fear), and the arch-specific code for this can simply take care not
> to touch the stack (eg, for i386 we just make fix_processor_context
> and do_fpu_end out-of-line).
> It feels cleaner than altering register that look like stack
> Am I making any sense this morning? =)
Sort of. Sorry for the overquote, but I couldn't find anything to strip.
After restore_processor_context() we have the old stack and old frame
pointers, so how can accesses to %ebp(x) work for any x? Actually, this is
one thing I've been wondering about for quite a while. We restore the
stack from within save_image but who guarantees that after
restore_processor_context() we have any usable amount of local stack
space? I think all the functions that we call after that should really be
noinline as well.
OTOH, if that is not a problem, then it doesn't matter and we can have
just copyback_low() noinline and that's all...
Not sure. I need to draw some diagrams to understand this.
More information about the TuxOnIce-devel