blob: 07018846b8165803cea7d3f5b0aa87f1ba372924 [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
40
41System call handlers
42~~~~~~~~~~~~~~~~~~~~
43The pre/post functions should be factored into: marshallers, which get
44the syscall args from wherever they live, and handlers proper, which
45do whatever pre/post checks/hanldling is needed. The handlers are
46more or less platform independent. The marshallers insulate the
47handlers from details of knowing how to get hold of syscall arg/result
48values given that different platforms use different and sometimes
49strange calling conventions.
50
51The syscall handlers assume that the result register (RES) does not
52overlap with any argument register (ARGn). They assume this by
53blithely referring to ARGn in the post-handlers. This should be fixed
54properly -- before the call, a copy of the args should be saved so
55they can be safely inspected after the call.
56
57The mechanisms by which a pre-handler can complete a syscall itself
58without handing it off to the kernel need to be cleaned up. The
59"Special" syscall designation no longer really makes sense (it never
60did) and should be removed.
61
62
63