sewardj | f15bba6 | 2005-03-02 14:22:49 +0000 | [diff] [blame^] | 1 | |
| 2 | Cleanup notes. JRS, started 2 March 05. |
| 3 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 4 | |
| 5 | The following cleanups need to be done. |
| 6 | |
| 7 | AMD64 vsyscalls |
| 8 | ~~~~~~~~~~~~~~~ |
| 9 | The redirect mechanism should (could) be used to support vsyscalls on |
| 10 | both amd64 and x86, by redirecting jumps to the vsyscall entry |
| 11 | point(s) to appropriate helper stubs instead. There is no point in |
| 12 | using the current x86 scheme of copying the trampoline code around the |
| 13 | place and making the AT_SYSINFO entry point at it, as that mechanism |
| 14 | does not work on amd64. |
| 15 | |
| 16 | On x86-linux, the vsyscall address is whatever the AT_SYSINFO entry |
| 17 | says it is. Reroute all jumps to that to a suitable stub. |
| 18 | |
| 19 | On amd64, there are multiple vsyscall entry points at -10M + |
| 20 | 1024*vsyscall_no (currently there are only two). These each need to be |
| 21 | redirected to suitable stubs which do normal syscalls instead. |
| 22 | |
| 23 | These redirects should be set up as part of platform-specific |
| 24 | initialisation sequences. They should not be set up as at present in |
| 25 | vg_symtab2.c. All this stuff should be within platform-specific |
| 26 | startup code, and should not be visible in generic core service code. |
| 27 | |
| 28 | |
| 29 | Redirection mechanism |
| 30 | ~~~~~~~~~~~~~~~~~~~~~ |
| 31 | Uses the skiplist mechanism. How it works is opaque and undocumented. |
| 32 | This code should be ripped out and replaced with something |
| 33 | maintainable. The list of unresolved redirections should be a |
| 34 | seperate data structure from the currently active (addr, addr) |
| 35 | mapping. |
| 36 | |
| 37 | There's a whole big #ifdef TEST section in vg_symtab2.c which has |
| 38 | no apparent purpose. |
| 39 | |
| 40 | |
| 41 | System call handlers |
| 42 | ~~~~~~~~~~~~~~~~~~~~ |
| 43 | The pre/post functions should be factored into: marshallers, which get |
| 44 | the syscall args from wherever they live, and handlers proper, which |
| 45 | do whatever pre/post checks/hanldling is needed. The handlers are |
| 46 | more or less platform independent. The marshallers insulate the |
| 47 | handlers from details of knowing how to get hold of syscall arg/result |
| 48 | values given that different platforms use different and sometimes |
| 49 | strange calling conventions. |
| 50 | |
| 51 | The syscall handlers assume that the result register (RES) does not |
| 52 | overlap with any argument register (ARGn). They assume this by |
| 53 | blithely referring to ARGn in the post-handlers. This should be fixed |
| 54 | properly -- before the call, a copy of the args should be saved so |
| 55 | they can be safely inspected after the call. |
| 56 | |
| 57 | The mechanisms by which a pre-handler can complete a syscall itself |
| 58 | without handing it off to the kernel need to be cleaned up. The |
| 59 | "Special" syscall designation no longer really makes sense (it never |
| 60 | did) and should be removed. |
| 61 | |
| 62 | |
| 63 | |