NOTES.txt

13 May 05
~~~~~~~~~
ToDo: (arch)/dispatch.S: In dispatch_exceptional, there's no point
testing the guest code return value against VG_TRC_INNER_COUNTERZERO,
as vex never sets this flag.  Need to check to see if it's possible to
completely get rid of VG_TRC_INNER_COUNTERZERO.


11 May 05
~~~~~~~~~
ToDo: vex-amd64: check above/below the line for reg-alloc


23 Apr 05 (memcheck-on-amd64 notes)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* If a thread is given an initial stack with address range [lo .. hi],
  we need to tell memcheck that the area [lo - VGA_STACK_REDZONE_SZB
  .. hi] is valid, rather than just [lo .. hi] as has been the case on
  x86-only systems.  However, am not sure where to look for the call
  into memcheck that states the new stack area.


9 Apr 05 (starting work on memcheck for 32/64-bit and big/little endian)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* get rid of include/tool_asm.h.  I think 
  this is left over from single-platform days, when it made
  sense to have tool-helpers written in assembly.  Looks like we
  need to retain coregrind/core_asm.h, though.

  [tool_asm.h will need to remain in some form -- there are still assembly
  files that need to see VG_() and related macros. --njn]


23 March 05
~~~~~~~~~~~
Do we still need ARCH_PTHREQ_RET (or *PTHREQ* for that matter) ?

Notes pertaining to the 2.4.0 - 3.0 merge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As of 10 March (svn rev 3266, vex svn rev 1019) the merged code base
can start and run programs with --tool=none.  Both threaded and
unthreaded programs appear to work (knode, opera, konqueror).

Known breakage is:

* Basically only x86 works.  I was part-way through getting amd64
  to work when I stopped to do the merge.  I think you can assume
  amd64 is pretty much knackered right now.

* No other tools work.  Memcheck worked fine in 3.0 prior to the
  merge but needs to have Jeremy's space-saving hacks folded in.
  Also the leak checker improvements.  Ditto addrcheck.
  Cachegrind is broken because it is not Vex-aware, and Vex needs
  to be changed to convey info on instruction boundaries to it.
  Helgrind is not Vex aware.  Also, Helgrind will not work because
  thread-event-modelling does not work (see below).  Memcheck
  and Addrcheck could be made to work with minor effort, and
  that should happen asap.  Cachegrind also needs to be fixed
  shortly.

* Function wrapping a la 2.4.0 is disabled, and will likely remain
  disabled for an extended period until I consider the software
  engineering consequences of it, specifically if a cleaner
  implementation is possible.  Result of that is that thread-event
  modelling and Helgrind are also disabled for that period.

* signal contexts for x86 signal deliveries are partially broken.  On
  delivery of an rt-signal, a context frame is built, but only the 8
  integer registers and %eflags are written into it, no SSE and no FP
  state.  Also, the vcpu state is restored on return to whatever it
  was before the signal was delivered; it is not restored from the
  sigcontext offered to the handler.  That means handlers which
  expect to be able to modify the machine state will not work.
  This will be fixed; it requires a small amount of work on the
  Vex side.

* I got rid of extra UInt* flags arg for syscall pre wrappers,
  so they can't add MayBlock after examining the args.  Should
  be reinstated.  I commented out various *flags |= MayBlock"
  so they can easily enough be put back in.

* Tracking of device segments is somehow broken (I forget how)

* Core dumping is disabled (has been for a while in the 3.0 line)
  because it needs to be factored per arch (or is it per arch+os).


Other notes I made:

* Check tests/filter_stderr_basic; I got confused whilst merging it

* Dubious use of setjmp in run_thread_for_a_while -- I thought it
  was only OK to use setjmp as the arg of an if:  if (setjmp(...)) ...

* EmWarn/Int confusion -- what type is it in the guest state?

* Reinstate per-thread dispatch ctrs.  First find out what the
  rationale for per-thread counters is.

* main: TL_(fini) is not given exitcode and it should be.

* Prototype for VG_(_client_syscall) [note leading _] is in a 
  bad place.

(It was a 3-way merge, using the most recent common ancestor
 of the 2.4.0 and 3.0 lines:

   cvs co -D "11/19/2004 17:45:00 GMT" valgrind

 and the 2.4.0 line

   obtained at Fri Mar  4 15:52:46 GMT 2005 by:
   cvs co valgrind

 and the 3.0 line, which is svn revision 3261.
)


Cleanup notes derived from making AMD64 work.  JRS, started 2 March 05.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following cleanups need to be done.

AMD64 vsyscalls
~~~~~~~~~~~~~~~
The redirect mechanism should (could) be used to support vsyscalls on
both amd64 and x86, by redirecting jumps to the vsyscall entry
point(s) to appropriate helper stubs instead.  There is no point in
using the current x86 scheme of copying the trampoline code around the
place and making the AT_SYSINFO entry point at it, as that mechanism
does not work on amd64.

On x86-linux, the vsyscall address is whatever the AT_SYSINFO entry
says it is.  Reroute all jumps to that to a suitable stub.

On amd64, there are multiple vsyscall entry points at -10M +
1024*vsyscall_no (currently there are only two). These each need to be
redirected to suitable stubs which do normal syscalls instead.

These redirects should be set up as part of platform-specific
initialisation sequences.  They should not be set up as at present in
vg_symtab2.c.  All this stuff should be within platform-specific
startup code, and should not be visible in generic core service code.


Redirection mechanism
~~~~~~~~~~~~~~~~~~~~~
How this works is difficult to understand.  This should be fixed.  The
list of unresolved redirections should be a seperate data structure
from the currently active (addr, addr) mapping.

There's a whole big #ifdef TEST section in vg_symtab2.c which has
no apparent purpose.

The redirecting-symtab-loader seems like a good idea on the face
of it: you can write functions whose name says, in effect
  "i_am_a_replacement_for_FOO"
and then all jumps/calls to FOO get redirected there.  Problem is
that nameing mechanism involves $ signs etc in symbol names, which
makes it very fragile.  TODO: (1) figure out if we still need
this, and if so (2) fix.


System call handlers
~~~~~~~~~~~~~~~~~~~~
The pre/post functions should be factored into: marshallers, which get
the syscall args from wherever they live, and handlers proper, which
do whatever pre/post checks/hanldling is needed.  The handlers are
more or less platform independent.  The marshallers insulate the
handlers from details of knowing how to get hold of syscall arg/result
values given that different platforms use different and sometimes
strange calling conventions.

The syscall handlers assume that the result register (RES) does not
overlap with any argument register (ARGn).  They assume this by
blithely referring to ARGn in the post-handlers.  This should be fixed
properly -- before the call, a copy of the args should be saved so
they can be safely inspected after the call.

The mechanisms by which a pre-handler can complete a syscall itself
without handing it off to the kernel need to be cleaned up.  The
"Special" syscall designation no longer really makes sense (it never
did) and should be removed.

Sockets: move the socketcall marshaller from vg_syscalls.c into
x86-linux/syscalls.c; it is in the wrong place.