docs/internals/notes.txt

   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 separate 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