|
From: Kailash S. <hs...@gm...> - 2006-09-05 04:36:51
|
Hi,
Firstly my apologies for digressing from the actual discussion on
Valgrind 3.3, but this pertains to both the regtest framework and the
new ports.
With regards to the NetBSD/i386 port of Valgrind, we have been making
quiet progress and have been doing so with the view of our code
finding its way back into the main tree sometime in the future. The
snapshot of valgrind our code is based on is somewhere between 3.1 and
3.2, as we have already merged code from -current two times before,
regular merges should not be a problem.
On Sunday 3rd Sept, we finally managed to get our port to debug
simple programs under NetBSD/i386. Memcheck is now able to detect most
leaks and read symbols correctly ( displaying proper stack traces).
Valgrind is able to run dynamic binaries under it in a proper manner.
The missing bits are the syscall wrapper implementations for many
syscalls.
In various places, such as mainly the syscall handling code, we have
had no choice but to put in 'dirty hacks'. For example, one major area
is around syscall handling, where NetBSD passes syscall arguments via
stack rather than registers. While most of this code is abstracted,
the abstraction assumes linux's pass-by-register semantics ( the
workings of syswrap-main.c using offsets in libvex_guest_offsets.h to
grab arguments out of VexGuestX86State ).
As we try to keep our codebase mergable , a lot of hacks have gone
into place without redoing this framework. In this case, we use
special 'offsets' here to query the stack in
{get/set}_shadow_regs_area in m_machine.c.
This sort of changes will also benifit other ports such as Darwin/i386
and FreeBSD port.
Currently, we are in the process of making the regtest framework work
correctly, as there are quite a few linuxisms in the code. This will
be crucial for us in determining exactly where further porting work is
required, as correctness is most important.
There are also other minor niggles in our codebase around Makefiles
especially, which require to be cleaned up before we can put a tarball
of a mostly-working valgrind for netbsd up. ( Dependancy on GNU Sed,
some symlink issues in the .in_place/ dir etc).
Our intention was to report our progress after the regtest framework
was fixed as that would give us some concrete statistics to show and
after fixing the minor niggles, however this e-mail seemed to be a
good avenue to discuss the progress of this new port.
The project page is at http://vg4nbsd.berlios.de
We would be more than happy to help in getting the regtest framework
in shape, and also maybe a side discussion on abstracting some
frameworks a bit more to help the non linux port would be of good
benifit, and help us share code as much as we can, among new ports.
Regards,
Kailash
>
> New ports for 3.3.0
> ~~~~~~~~~~~~~~~~~~~
> This year there has been quiet but steady work towards porting V away
> from Linux. There are now ports to FreeBSD, MacOSX and AIX5 in
> various states of progress, and it seems likely that some of those
> will appear in the mainline tree at some point.
>
> I am expecting that our existing porting infrastructure will continue
> to be refined and extended so that these ports can be accommodated
> without majorly intrusive changes in the majority of the code base.
> So far with the Linux ports to x86,amd64,ppc32,ppc64, the
> target-specific stuff has been isolated into a relatively few places
> (eg, m_syswrap, m_sigframe, m_syscall, VEX), leaving the rest of the
> system fairly untouched, and I am hoping this can be continued.
>
> The regression test infrastructure has proven invaluable in making V
> as reliable as it is. However, even with Linux it is too sensitive to
> changes in stack backtraces and address space layouts, and as a result
> causes tests to fail when really they should succeed. With new ports
> on the horizon this problem is about to get much worse. If anyone is
> motivated to overhaul this unglamorous but critical subsystem, that
> would be much appreciated.
|