11 May 05 ~~~~~~~~~ ToDo: vex-amd64: check above/below the line for reg-alloc 23 Apr 05 (memcheck-on-amd64 notes) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * If a thread is given an initial stack with address range [lo .. hi], we need to tell memcheck that the area [lo - VGA_STACK_REDZONE_SZB .. hi] is valid, rather than just [lo .. hi] as has been the case on x86-only systems. However, am not sure where to look for the call into memcheck that states the new stack area. 9 Apr 05 (starting work on memcheck for 32/64-bit and big/little endian) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * get rid of include/tool_asm.h. I think this is left over from single-platform days, when it made sense to have tool-helpers written in assembly. Looks like we need to retain coregrind/core_asm.h, though. [tool_asm.h will need to remain in some form -- there are still assembly files that need to see VG_() and related macros. --njn] 23 March 05 ~~~~~~~~~~~ Do we still need ARCH_PTHREQ_RET (or *PTHREQ* for that matter) ? Notes pertaining to the 2.4.0 - 3.0 merge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As of 10 March (svn rev 3266, vex svn rev 1019) the merged code base can start and run programs with --tool=none. Both threaded and unthreaded programs appear to work (knode, opera, konqueror). Known breakage is: * Basically only x86 works. I was part-way through getting amd64 to work when I stopped to do the merge. I think you can assume amd64 is pretty much knackered right now. * No other tools work. Memcheck worked fine in 3.0 prior to the merge but needs to have Jeremy's space-saving hacks folded in. Also the leak checker improvements. Ditto addrcheck. Cachegrind is broken because it is not Vex-aware, and Vex needs to be changed to convey info on instruction boundaries to it. Helgrind is not Vex aware. Also, Helgrind will not work because thread-event-modelling does not work (see below). Memcheck and Addrcheck could be made to work with minor effort, and that should happen asap. Cachegrind also needs to be fixed shortly. * Function wrapping a la 2.4.0 is disabled, and will likely remain disabled for an extended period until I consider the software engineering consequences of it, specifically if a cleaner implementation is possible. Result of that is that thread-event modelling and Helgrind are also disabled for that period. * signal contexts for x86 signal deliveries are partially broken. On delivery of an rt-signal, a context frame is built, but only the 8 integer registers and %eflags are written into it, no SSE and no FP state. Also, the vcpu state is restored on return to whatever it was before the signal was delivered; it is not restored from the sigcontext offered to the handler. That means handlers which expect to be able to modify the machine state will not work. This will be fixed; it requires a small amount of work on the Vex side. * I got rid of extra UInt* flags arg for syscall pre wrappers, so they can't add MayBlock after examining the args. Should be reinstated. I commented out various *flags |= MayBlock" so they can easily enough be put back in. * Tracking of device segments is somehow broken (I forget how) * Core dumping is disabled (has been for a while in the 3.0 line) because it needs to be factored per arch (or is it per arch+os). Other notes I made: * Check tests/filter_stderr_basic; I got confused whilst merging it * Dubious use of setjmp in run_thread_for_a_while -- I thought it was only OK to use setjmp as the arg of an if: if (setjmp(...)) ... * EmWarn/Int confusion -- what type is it in the guest state? * Reinstate per-thread dispatch ctrs. First find out what the rationale for per-thread counters is. * main: TL_(fini) is not given exitcode and it should be. * Prototype for VG_(_client_syscall) [note leading _] is in a bad place. (It was a 3-way merge, using the most recent common ancestor of the 2.4.0 and 3.0 lines: cvs co -D "11/19/2004 17:45:00 GMT" valgrind and the 2.4.0 line obtained at Fri Mar 4 15:52:46 GMT 2005 by: cvs co valgrind and the 3.0 line, which is svn revision 3261. ) Cleanup notes derived from making AMD64 work. 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 ~~~~~~~~~~~~~~~~~~~~~ How this works is difficult to understand. This should be fixed. 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.