Home | History | Annotate | Download | only in internals
      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 
      8 11 May 05
      9 ~~~~~~~~~
     10 ToDo: vex-amd64: check above/below the line for reg-alloc
     11 
     12 23 Apr 05 (memcheck-on-amd64 notes)
     13 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     14 * If a thread is given an initial stack with address range [lo .. hi],
     15   we need to tell memcheck that the area [lo - VGA_STACK_REDZONE_SZB
     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.
     19 
     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).
     25 
     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 
     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 
     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 
     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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    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 ~~~~~~~~~~~~~~~~~~~~~
    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.
    132 
    133 There's a whole big #ifdef TEST section in vg_symtab2.c which has
    134 no apparent purpose.
    135 
    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 
    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 
    166 Sockets: move the socketcall marshaller from vg_syscalls.c into
    167 x86-linux/syscalls.c; it is in the wrong place.
    168 
    169