1 20 Jun 05 2 ~~~~~~~~~ 3 PPC32 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 8 11 May 05 9 ~~~~~~~~~ 10 ToDo: vex-amd64: check above/below the line for reg-alloc 11 12 23 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 20 Notes pertaining to the 2.4.0 - 3.0 merge 21 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 22 As of 10 March (svn rev 3266, vex svn rev 1019) the merged code base 23 can start and run programs with --tool=none. Both threaded and 24 unthreaded programs appear to work (knode, opera, konqueror). 25 26 Known 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 70 Other 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 101 Cleanup notes derived from making AMD64 work. JRS, started 2 March 05. 102 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 103 The following cleanups need to be done. 104 105 AMD64 vsyscalls 106 ~~~~~~~~~~~~~~~ 107 The redirect mechanism should (could) be used to support vsyscalls on 108 both amd64 and x86, by redirecting jumps to the vsyscall entry 109 point(s) to appropriate helper stubs instead. There is no point in 110 using the current x86 scheme of copying the trampoline code around the 111 place and making the AT_SYSINFO entry point at it, as that mechanism 112 does not work on amd64. 113 114 On x86-linux, the vsyscall address is whatever the AT_SYSINFO entry 115 says it is. Reroute all jumps to that to a suitable stub. 116 117 On amd64, there are multiple vsyscall entry points at -10M + 118 1024*vsyscall_no (currently there are only two). These each need to be 119 redirected to suitable stubs which do normal syscalls instead. 120 121 These redirects should be set up as part of platform-specific 122 initialisation sequences. They should not be set up as at present in 123 vg_symtab2.c. All this stuff should be within platform-specific 124 startup code, and should not be visible in generic core service code. 125 126 127 Redirection mechanism 128 ~~~~~~~~~~~~~~~~~~~~~ 129 How this works is difficult to understand. This should be fixed. The 130 list of unresolved redirections should be a separate data structure 131 from the currently active (addr, addr) mapping. 132 133 There's a whole big #ifdef TEST section in vg_symtab2.c which has 134 no apparent purpose. 135 136 The redirecting-symtab-loader seems like a good idea on the face 137 of it: you can write functions whose name says, in effect 138 "i_am_a_replacement_for_FOO" 139 and then all jumps/calls to FOO get redirected there. Problem is 140 that nameing mechanism involves $ signs etc in symbol names, which 141 makes it very fragile. TODO: (1) figure out if we still need 142 this, and if so (2) fix. 143 144 145 System call handlers 146 ~~~~~~~~~~~~~~~~~~~~ 147 The pre/post functions should be factored into: marshallers, which get 148 the syscall args from wherever they live, and handlers proper, which 149 do whatever pre/post checks/hanldling is needed. The handlers are 150 more or less platform independent. The marshallers insulate the 151 handlers from details of knowing how to get hold of syscall arg/result 152 values given that different platforms use different and sometimes 153 strange calling conventions. 154 155 The syscall handlers assume that the result register (RES) does not 156 overlap with any argument register (ARGn). They assume this by 157 blithely referring to ARGn in the post-handlers. This should be fixed 158 properly -- before the call, a copy of the args should be saved so 159 they can be safely inspected after the call. 160 161 The mechanisms by which a pre-handler can complete a syscall itself 162 without handing it off to the kernel need to be cleaned up. The 163 "Special" syscall designation no longer really makes sense (it never 164 did) and should be removed. 165 166 Sockets: move the socketcall marshaller from vg_syscalls.c into 167 x86-linux/syscalls.c; it is in the wrong place. 168 169
