120 Jun 05
2~~~~~~~~~
3PPC32 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
811 May 05
9~~~~~~~~~
10ToDo: vex-amd64: check above/below the line for reg-alloc
11
1223 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
20Notes pertaining to the 2.4.0 - 3.0 merge
21~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
22As of 10 March (svn rev 3266, vex svn rev 1019) the merged code base
23can start and run programs with --tool=none.  Both threaded and
24unthreaded programs appear to work (knode, opera, konqueror).
25
26Known 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
70Other 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
101Cleanup notes derived from making AMD64 work.  JRS, started 2 March 05.
102~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
103The following cleanups need to be done.
104
105AMD64 vsyscalls
106~~~~~~~~~~~~~~~
107The redirect mechanism should (could) be used to support vsyscalls on
108both amd64 and x86, by redirecting jumps to the vsyscall entry
109point(s) to appropriate helper stubs instead.  There is no point in
110using the current x86 scheme of copying the trampoline code around the
111place and making the AT_SYSINFO entry point at it, as that mechanism
112does not work on amd64.
113
114On x86-linux, the vsyscall address is whatever the AT_SYSINFO entry
115says it is.  Reroute all jumps to that to a suitable stub.
116
117On amd64, there are multiple vsyscall entry points at -10M +
1181024*vsyscall_no (currently there are only two). These each need to be
119redirected to suitable stubs which do normal syscalls instead.
120
121These redirects should be set up as part of platform-specific
122initialisation sequences.  They should not be set up as at present in
123vg_symtab2.c.  All this stuff should be within platform-specific
124startup code, and should not be visible in generic core service code.
125
126
127Redirection mechanism
128~~~~~~~~~~~~~~~~~~~~~
129How this works is difficult to understand.  This should be fixed.  The
130list of unresolved redirections should be a seperate data structure
131from the currently active (addr, addr) mapping.
132
133There's a whole big #ifdef TEST section in vg_symtab2.c which has
134no apparent purpose.
135
136The redirecting-symtab-loader seems like a good idea on the face
137of it: you can write functions whose name says, in effect
138  "i_am_a_replacement_for_FOO"
139and then all jumps/calls to FOO get redirected there.  Problem is
140that nameing mechanism involves $ signs etc in symbol names, which
141makes it very fragile.  TODO: (1) figure out if we still need
142this, and if so (2) fix.
143
144
145System call handlers
146~~~~~~~~~~~~~~~~~~~~
147The pre/post functions should be factored into: marshallers, which get
148the syscall args from wherever they live, and handlers proper, which
149do whatever pre/post checks/hanldling is needed.  The handlers are
150more or less platform independent.  The marshallers insulate the
151handlers from details of knowing how to get hold of syscall arg/result
152values given that different platforms use different and sometimes
153strange calling conventions.
154
155The syscall handlers assume that the result register (RES) does not
156overlap with any argument register (ARGn).  They assume this by
157blithely referring to ARGn in the post-handlers.  This should be fixed
158properly -- before the call, a copy of the args should be saved so
159they can be safely inspected after the call.
160
161The mechanisms by which a pre-handler can complete a syscall itself
162without handing it off to the kernel need to be cleaned up.  The
163"Special" syscall designation no longer really makes sense (it never
164did) and should be removed.
165
166Sockets: move the socketcall marshaller from vg_syscalls.c into
167x86-linux/syscalls.c; it is in the wrong place.
168
169