Messages in this thread | | | Date | Mon, 3 Feb 1997 21:06:31 +0100 (MET) | From | Ingo Molnar <> | Subject | Re: csum_partial_copy_fromuser patch, #2 |
| |
On Mon, 3 Feb 1997, Jakub Jelinek wrote:
> [...] The fixup would then look down callee's pc, look in there to see > if exception handling wanted. [...]
how do you do this? GCC is free to do anything with the stack. If anything in the stack layout changes (ie. a parameter definition changes), we've got to change the assembly section too. [and the only 'sign' of being broken is that the code crashes]
__builtin_return_address(0) is unreliable AFAIK if -fomit-frame-pointer, which we use happily in the kernel btw.
anyone knows whether anything ugly happens to checksum.c if -fno-omit-frame-pointer is added to the Makefile?
[... a few seconds pass: recompiling -fno-omit-frame-pointer -S]
well, when using -fno-omit-frame-pointer, we get (two) extra new instructions into the hot path ... this is almost equivalent to doing runtime parameter passing ...
So we have two alternatives:
1) having more instances of conceptually similar functions 2) analyzing the stack layout for each compiler and calling environment change.
i think we shouldnt go 2). [unless there is a safe way to detect the stack layout being broken, or to access the return IP in a guaranteed way?]
[ do you guys see what's happening? Our clever and tricky exception concept wants to leak towards other code ... now it wants to 'pass exceptions across function call boundaries'. Because the compiler doesnt know about them in a proper way, we are slowly getting bigger and bigger problems ... after these checksum things are settled, IMHO we should freeze further misuse of this 'feature' ? ;) ]
well, we could build our private function call interface into one single __asm__ block (thus it's us who controls the stack layout) ... but this way we prevent GCC from optimizing stack layout things.
we loose whatever way we go, i'm afraid. Help! ;)
-- mingo
| |