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 | |
sewardj | 6941a1a | 2005-03-02 16:01:23 +0000 | [diff] [blame^] | 40 | The redirecting-symtab-loader seems like a good idea on the face |
| 41 | of it: you can write functions whose name says, in effect |
| 42 | "i_am_a_replacement_for_FOO" |
| 43 | and then all jumps/calls to FOO get redirected there. Problem is |
| 44 | that nameing mechanism involves $ signs etc in symbol names, which |
| 45 | makes it very fragile. TODO: (1) figure out if we still need |
| 46 | this, and if so (2) fix. |
| 47 | |
sewardj | f15bba6 | 2005-03-02 14:22:49 +0000 | [diff] [blame] | 48 | |
| 49 | System call handlers |
| 50 | ~~~~~~~~~~~~~~~~~~~~ |
| 51 | The pre/post functions should be factored into: marshallers, which get |
| 52 | the syscall args from wherever they live, and handlers proper, which |
| 53 | do whatever pre/post checks/hanldling is needed. The handlers are |
| 54 | more or less platform independent. The marshallers insulate the |
| 55 | handlers from details of knowing how to get hold of syscall arg/result |
| 56 | values given that different platforms use different and sometimes |
| 57 | strange calling conventions. |
| 58 | |
| 59 | The syscall handlers assume that the result register (RES) does not |
| 60 | overlap with any argument register (ARGn). They assume this by |
| 61 | blithely referring to ARGn in the post-handlers. This should be fixed |
| 62 | properly -- before the call, a copy of the args should be saved so |
| 63 | they can be safely inspected after the call. |
| 64 | |
| 65 | The mechanisms by which a pre-handler can complete a syscall itself |
| 66 | without handing it off to the kernel need to be cleaned up. The |
| 67 | "Special" syscall designation no longer really makes sense (it never |
| 68 | did) and should be removed. |
| 69 | |
sewardj | 6941a1a | 2005-03-02 16:01:23 +0000 | [diff] [blame^] | 70 | Sockets: move the socketcall marshaller from vg_syscalls.c into |
| 71 | x86-linux/syscalls.c; it is in the wrong place. |
sewardj | f15bba6 | 2005-03-02 14:22:49 +0000 | [diff] [blame] | 72 | |