valgrind/docs/internals/notes.txt - nest-cam/4320010/valgrind - Git at Google

 20 Jun 05
 ~~~~~~~~~
 PPC32 port
 * Paul wrote some code to deal with setting/clearing reservations.
   (grep USE_MACHINE_RESERVATION, ARCH_SWITCH_TO, lwarx, stwcx.)
   Not yet looked into, but this may be needed.

 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.

 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.
	20 Jun 05
	~~~~~~~~~
	PPC32 port
	* Paul wrote some code to deal with setting/clearing reservations.
	(grep USE_MACHINE_RESERVATION, ARCH_SWITCH_TO, lwarx, stwcx.)
	Not yet looked into, but this may be needed.

	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.

	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.