mirror of
https://github.com/ioacademy-jikim/debugging
synced 2025-06-08 08:26:14 +00:00
169 lines
6.7 KiB
Plaintext
169 lines
6.7 KiB
Plaintext
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.
|
|
|