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