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