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