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