>> Wow, that's intuitive :)
>> They're trying to access the variables that have been pushed onto the
>> top of the stack. The thread_info field points to the bottom of the
>> kernel's stack (no matter how big it is). I don't know where the -5 and
>> -2 come from. It needs a big, fat stinking comment.
>
> I'm not 100% convinced it DTRT on modern kernels. I vaguely wonder if
> the following would be more appropriate. Shame the typedef isn't there
> yet; the _struct suffix is an eyesore.
So are the new bits of the patch related to the KSTK_E* bit?
They don't seem to be ... however, this bit looks really good:
> -#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1019])
> -#define KSTK_ESP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1022])
> +#define KSTK_EIP(task) ((task)->thread.eip)
> +#define KSTK_ESP(task) ((task)->thread.esp)
Can I assume it's tested, or does it need someone to do that?
Thanks,
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:43 EST