blob: f63f16c53869b7d145d966ad4d9fe7a7ededba28 [file] [log] [blame]
sewardjf15bba62005-03-02 14:22:49 +00001
2Cleanup notes. JRS, started 2 March 05.
3~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4
5The following cleanups need to be done.
6
7AMD64 vsyscalls
8~~~~~~~~~~~~~~~
9The redirect mechanism should (could) be used to support vsyscalls on
10both amd64 and x86, by redirecting jumps to the vsyscall entry
11point(s) to appropriate helper stubs instead. There is no point in
12using the current x86 scheme of copying the trampoline code around the
13place and making the AT_SYSINFO entry point at it, as that mechanism
14does not work on amd64.
15
16On x86-linux, the vsyscall address is whatever the AT_SYSINFO entry
17says it is. Reroute all jumps to that to a suitable stub.
18
19On amd64, there are multiple vsyscall entry points at -10M +
201024*vsyscall_no (currently there are only two). These each need to be
21redirected to suitable stubs which do normal syscalls instead.
22
23These redirects should be set up as part of platform-specific
24initialisation sequences. They should not be set up as at present in
25vg_symtab2.c. All this stuff should be within platform-specific
26startup code, and should not be visible in generic core service code.
27
28
29Redirection mechanism
30~~~~~~~~~~~~~~~~~~~~~
31Uses the skiplist mechanism. How it works is opaque and undocumented.
32This code should be ripped out and replaced with something
33maintainable. The list of unresolved redirections should be a
34seperate data structure from the currently active (addr, addr)
35mapping.
36
37There's a whole big #ifdef TEST section in vg_symtab2.c which has
38no apparent purpose.
39
sewardj6941a1a2005-03-02 16:01:23 +000040The redirecting-symtab-loader seems like a good idea on the face
41of it: you can write functions whose name says, in effect
42 "i_am_a_replacement_for_FOO"
43and then all jumps/calls to FOO get redirected there. Problem is
44that nameing mechanism involves $ signs etc in symbol names, which
45makes it very fragile. TODO: (1) figure out if we still need
46this, and if so (2) fix.
47
sewardjf15bba62005-03-02 14:22:49 +000048
49System call handlers
50~~~~~~~~~~~~~~~~~~~~
51The pre/post functions should be factored into: marshallers, which get
52the syscall args from wherever they live, and handlers proper, which
53do whatever pre/post checks/hanldling is needed. The handlers are
54more or less platform independent. The marshallers insulate the
55handlers from details of knowing how to get hold of syscall arg/result
56values given that different platforms use different and sometimes
57strange calling conventions.
58
59The syscall handlers assume that the result register (RES) does not
60overlap with any argument register (ARGn). They assume this by
61blithely referring to ARGn in the post-handlers. This should be fixed
62properly -- before the call, a copy of the args should be saved so
63they can be safely inspected after the call.
64
65The mechanisms by which a pre-handler can complete a syscall itself
66without handing it off to the kernel need to be cleaned up. The
67"Special" syscall designation no longer really makes sense (it never
68did) and should be removed.
69
sewardj6941a1a2005-03-02 16:01:23 +000070Sockets: move the socketcall marshaller from vg_syscalls.c into
71x86-linux/syscalls.c; it is in the wrong place.
sewardjf15bba62005-03-02 14:22:49 +000072
sewardj80fe8af2005-03-10 13:28:41 +000073Tra La La