blob: f63f16c53869b7d145d966ad4d9fe7a7ededba28 [file] [log] [blame]
Cleanup notes. JRS, started 2 March 05.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following cleanups need to be done.
AMD64 vsyscalls
~~~~~~~~~~~~~~~
The redirect mechanism should (could) be used to support vsyscalls on
both amd64 and x86, by redirecting jumps to the vsyscall entry
point(s) to appropriate helper stubs instead. There is no point in
using the current x86 scheme of copying the trampoline code around the
place and making the AT_SYSINFO entry point at it, as that mechanism
does not work on amd64.
On x86-linux, the vsyscall address is whatever the AT_SYSINFO entry
says it is. Reroute all jumps to that to a suitable stub.
On amd64, there are multiple vsyscall entry points at -10M +
1024*vsyscall_no (currently there are only two). These each need to be
redirected to suitable stubs which do normal syscalls instead.
These redirects should be set up as part of platform-specific
initialisation sequences. They should not be set up as at present in
vg_symtab2.c. All this stuff should be within platform-specific
startup code, and should not be visible in generic core service code.
Redirection mechanism
~~~~~~~~~~~~~~~~~~~~~
Uses the skiplist mechanism. How it works is opaque and undocumented.
This code should be ripped out and replaced with something
maintainable. The list of unresolved redirections should be a
seperate data structure from the currently active (addr, addr)
mapping.
There's a whole big #ifdef TEST section in vg_symtab2.c which has
no apparent purpose.
The redirecting-symtab-loader seems like a good idea on the face
of it: you can write functions whose name says, in effect
"i_am_a_replacement_for_FOO"
and then all jumps/calls to FOO get redirected there. Problem is
that nameing mechanism involves $ signs etc in symbol names, which
makes it very fragile. TODO: (1) figure out if we still need
this, and if so (2) fix.
System call handlers
~~~~~~~~~~~~~~~~~~~~
The pre/post functions should be factored into: marshallers, which get
the syscall args from wherever they live, and handlers proper, which
do whatever pre/post checks/hanldling is needed. The handlers are
more or less platform independent. The marshallers insulate the
handlers from details of knowing how to get hold of syscall arg/result
values given that different platforms use different and sometimes
strange calling conventions.
The syscall handlers assume that the result register (RES) does not
overlap with any argument register (ARGn). They assume this by
blithely referring to ARGn in the post-handlers. This should be fixed
properly -- before the call, a copy of the args should be saved so
they can be safely inspected after the call.
The mechanisms by which a pre-handler can complete a syscall itself
without handing it off to the kernel need to be cleaned up. The
"Special" syscall designation no longer really makes sense (it never
did) and should be removed.
Sockets: move the socketcall marshaller from vg_syscalls.c into
x86-linux/syscalls.c; it is in the wrong place.
Tra La La