cerion | 85665ca | 2005-06-20 15:51:07 +0000 | [diff] [blame] | 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 | |
sewardj | 4ec8a63 | 2005-05-11 23:37:18 +0000 | [diff] [blame] | 8 | 11 May 05 |
| 9 | ~~~~~~~~~ |
sewardj | 0be2610 | 2005-05-14 11:18:31 +0000 | [diff] [blame] | 10 | ToDo: vex-amd64: check above/below the line for reg-alloc |
sewardj | 4ec8a63 | 2005-05-11 23:37:18 +0000 | [diff] [blame] | 11 | |
sewardj | 045a405 | 2005-04-23 22:42:27 +0000 | [diff] [blame] | 12 | 23 Apr 05 (memcheck-on-amd64 notes) |
| 13 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
sewardj | 9b3328d | 2005-04-24 00:04:42 +0000 | [diff] [blame] | 14 | * If a thread is given an initial stack with address range [lo .. hi], |
njn | a60a7c1 | 2005-05-08 17:49:37 +0000 | [diff] [blame] | 15 | we need to tell memcheck that the area [lo - VGA_STACK_REDZONE_SZB |
sewardj | 9b3328d | 2005-04-24 00:04:42 +0000 | [diff] [blame] | 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. |
sewardj | 045a405 | 2005-04-23 22:42:27 +0000 | [diff] [blame] | 19 | |
sewardj | 21c2581 | 2005-03-11 03:07:23 +0000 | [diff] [blame] | 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). |
sewardj | f15bba6 | 2005-03-02 14:22:49 +0000 | [diff] [blame] | 25 | |
sewardj | 21c2581 | 2005-03-11 03:07:23 +0000 | [diff] [blame] | 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 | |
sewardj | 21c2581 | 2005-03-11 03:07:23 +0000 | [diff] [blame] | 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 | |
sewardj | d1212b9 | 2005-03-11 12:43:19 +0000 | [diff] [blame] | 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 | |
sewardj | 21c2581 | 2005-03-11 03:07:23 +0000 | [diff] [blame] | 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 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
sewardj | f15bba6 | 2005-03-02 14:22:49 +0000 | [diff] [blame] | 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 | ~~~~~~~~~~~~~~~~~~~~~ |
sewardj | 21c2581 | 2005-03-11 03:07:23 +0000 | [diff] [blame] | 129 | How this works is difficult to understand. This should be fixed. The |
| 130 | list of unresolved redirections should be a seperate data structure |
| 131 | from the currently active (addr, addr) mapping. |
sewardj | f15bba6 | 2005-03-02 14:22:49 +0000 | [diff] [blame] | 132 | |
| 133 | There's a whole big #ifdef TEST section in vg_symtab2.c which has |
| 134 | no apparent purpose. |
| 135 | |
sewardj | 6941a1a | 2005-03-02 16:01:23 +0000 | [diff] [blame] | 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 | |
sewardj | f15bba6 | 2005-03-02 14:22:49 +0000 | [diff] [blame] | 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 | |
sewardj | 6941a1a | 2005-03-02 16:01:23 +0000 | [diff] [blame] | 166 | Sockets: move the socketcall marshaller from vg_syscalls.c into |
| 167 | x86-linux/syscalls.c; it is in the wrong place. |
sewardj | f15bba6 | 2005-03-02 14:22:49 +0000 | [diff] [blame] | 168 | |