120 Jun 05 2~~~~~~~~~ 3PPC32 port 4* Paul wrote some code to deal with setting/clearing reservations. 5 (grep USE_MACHINE_RESERVATION, ARCH_SWITCH_TO, lwarx, stwcx.) 6 Not yet looked into, but this may be needed. 7 811 May 05 9~~~~~~~~~ 10ToDo: vex-amd64: check above/below the line for reg-alloc 11 1223 Apr 05 (memcheck-on-amd64 notes) 13~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 14* If a thread is given an initial stack with address range [lo .. hi], 15 we need to tell memcheck that the area [lo - VGA_STACK_REDZONE_SZB 16 .. hi] is valid, rather than just [lo .. hi] as has been the case on 17 x86-only systems. However, am not sure where to look for the call 18 into memcheck that states the new stack area. 19 20Notes pertaining to the 2.4.0 - 3.0 merge 21~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 22As of 10 March (svn rev 3266, vex svn rev 1019) the merged code base 23can start and run programs with --tool=none. Both threaded and 24unthreaded programs appear to work (knode, opera, konqueror). 25 26Known breakage is: 27 28* Basically only x86 works. I was part-way through getting amd64 29 to work when I stopped to do the merge. I think you can assume 30 amd64 is pretty much knackered right now. 31 32* No other tools work. Memcheck worked fine in 3.0 prior to the 33 merge but needs to have Jeremy's space-saving hacks folded in. 34 Also the leak checker improvements. Ditto addrcheck. 35 Cachegrind is broken because it is not Vex-aware, and Vex needs 36 to be changed to convey info on instruction boundaries to it. 37 Helgrind is not Vex aware. Also, Helgrind will not work because 38 thread-event-modelling does not work (see below). Memcheck 39 and Addrcheck could be made to work with minor effort, and 40 that should happen asap. Cachegrind also needs to be fixed 41 shortly. 42 43* Function wrapping a la 2.4.0 is disabled, and will likely remain 44 disabled for an extended period until I consider the software 45 engineering consequences of it, specifically if a cleaner 46 implementation is possible. Result of that is that thread-event 47 modelling and Helgrind are also disabled for that period. 48 49* signal contexts for x86 signal deliveries are partially broken. On 50 delivery of an rt-signal, a context frame is built, but only the 8 51 integer registers and %eflags are written into it, no SSE and no FP 52 state. Also, the vcpu state is restored on return to whatever it 53 was before the signal was delivered; it is not restored from the 54 sigcontext offered to the handler. That means handlers which 55 expect to be able to modify the machine state will not work. 56 This will be fixed; it requires a small amount of work on the 57 Vex side. 58 59* I got rid of extra UInt* flags arg for syscall pre wrappers, 60 so they can't add MayBlock after examining the args. Should 61 be reinstated. I commented out various *flags |= MayBlock" 62 so they can easily enough be put back in. 63 64* Tracking of device segments is somehow broken (I forget how) 65 66* Core dumping is disabled (has been for a while in the 3.0 line) 67 because it needs to be factored per arch (or is it per arch+os). 68 69 70Other notes I made: 71 72* Check tests/filter_stderr_basic; I got confused whilst merging it 73 74* Dubious use of setjmp in run_thread_for_a_while -- I thought it 75 was only OK to use setjmp as the arg of an if: if (setjmp(...)) ... 76 77* EmWarn/Int confusion -- what type is it in the guest state? 78 79* Reinstate per-thread dispatch ctrs. First find out what the 80 rationale for per-thread counters is. 81 82* main: TL_(fini) is not given exitcode and it should be. 83 84* Prototype for VG_(_client_syscall) [note leading _] is in a 85 bad place. 86 87(It was a 3-way merge, using the most recent common ancestor 88 of the 2.4.0 and 3.0 lines: 89 90 cvs co -D "11/19/2004 17:45:00 GMT" valgrind 91 92 and the 2.4.0 line 93 94 obtained at Fri Mar 4 15:52:46 GMT 2005 by: 95 cvs co valgrind 96 97 and the 3.0 line, which is svn revision 3261. 98) 99 100 101Cleanup notes derived from making AMD64 work. JRS, started 2 March 05. 102~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 103The following cleanups need to be done. 104 105AMD64 vsyscalls 106~~~~~~~~~~~~~~~ 107The redirect mechanism should (could) be used to support vsyscalls on 108both amd64 and x86, by redirecting jumps to the vsyscall entry 109point(s) to appropriate helper stubs instead. There is no point in 110using the current x86 scheme of copying the trampoline code around the 111place and making the AT_SYSINFO entry point at it, as that mechanism 112does not work on amd64. 113 114On x86-linux, the vsyscall address is whatever the AT_SYSINFO entry 115says it is. Reroute all jumps to that to a suitable stub. 116 117On amd64, there are multiple vsyscall entry points at -10M + 1181024*vsyscall_no (currently there are only two). These each need to be 119redirected to suitable stubs which do normal syscalls instead. 120 121These redirects should be set up as part of platform-specific 122initialisation sequences. They should not be set up as at present in 123vg_symtab2.c. All this stuff should be within platform-specific 124startup code, and should not be visible in generic core service code. 125 126 127Redirection mechanism 128~~~~~~~~~~~~~~~~~~~~~ 129How this works is difficult to understand. This should be fixed. The 130list of unresolved redirections should be a separate data structure 131from the currently active (addr, addr) mapping. 132 133There's a whole big #ifdef TEST section in vg_symtab2.c which has 134no apparent purpose. 135 136The redirecting-symtab-loader seems like a good idea on the face 137of it: you can write functions whose name says, in effect 138 "i_am_a_replacement_for_FOO" 139and then all jumps/calls to FOO get redirected there. Problem is 140that nameing mechanism involves $ signs etc in symbol names, which 141makes it very fragile. TODO: (1) figure out if we still need 142this, and if so (2) fix. 143 144 145System call handlers 146~~~~~~~~~~~~~~~~~~~~ 147The pre/post functions should be factored into: marshallers, which get 148the syscall args from wherever they live, and handlers proper, which 149do whatever pre/post checks/hanldling is needed. The handlers are 150more or less platform independent. The marshallers insulate the 151handlers from details of knowing how to get hold of syscall arg/result 152values given that different platforms use different and sometimes 153strange calling conventions. 154 155The syscall handlers assume that the result register (RES) does not 156overlap with any argument register (ARGn). They assume this by 157blithely referring to ARGn in the post-handlers. This should be fixed 158properly -- before the call, a copy of the args should be saved so 159they can be safely inspected after the call. 160 161The mechanisms by which a pre-handler can complete a syscall itself 162without handing it off to the kernel need to be cleaned up. The 163"Special" syscall designation no longer really makes sense (it never 164did) and should be removed. 165 166Sockets: move the socketcall marshaller from vg_syscalls.c into 167x86-linux/syscalls.c; it is in the wrong place. 168 169