Status report

[Peter Bex]

The idea is to keep replying to this thread so everyone is kept uptodate on
the status of this project.

Right now we're still in the "sync to valgrind mainline" stage.
Their branch: svn://svn.valgrind.org/valgrind/trunk
The revision we're working off is fixed: rev 5230
Our branch: svn+ssh://svn.berlios.de/svnroot/repos/vg4nbsd/branches/aspacem

Currently I've synced the (Auto)Makefile structure in root and under
coregrind and include. Consider all tools (and Vex?) to be in need of
syncing.

The valgrind/coregrind and valgrind/include dirs have been fully updated.
Every file has been synched to Valgrind mainline, but we still need to iron
out some compile errors and such.

The rest (Valgrind tools) still needs to be updated and synched.

Vex is completely up to date.

Peter

[Peter Bex]

Hai,

Last time I said that coregrind was updated.... It wasn't. Only the
directory structure had been update (ie all files that had been removed
from their tree were removed from our tree and all files that had been added
in their tree were added in our tree)

Now the coregrind files are /really/ updated. ;)

We need to take a good look at m_trampoline.S, since there have been
significant changes there. m_main.c has seen a lot of changes too.

m_ume.c was hacked a bit by Kailash, but it also has some updates, so I hope
I didn't fudge up anything you did, Kailash...

Also, the stuff in m_syswrap needs to be taken under consideration. Stuff
has changed a lot there and I'm not sure which is ours and which has been
updated in V. I do remember we hacked that quite a bit... especially
where GENX_/LINX_ is concerned, so I didn't change those diffs.
We should discuss this on IRC.

In general, I get the impression the code has become a little cleaner, many
direct number comparisons have been replaced by constants and such.

I think we have a real chance of getting this thing to work!

Greetz,
Peter

[Kailash Sethuraman]

IFor stuff in coregrind, if it compiles, its fine for now.
Syswrap stuff is taken care of, dont worry.
m_main is a big thing, I did it partially, but it still needs to be done.
The biggest changes on syswrap were cleanups on the trunk, now generic
is really generic etc. For the syscalls most of ourse are I_die_here
stubs anyway, we can move ours around later when we implement the
calls, as that is the time when we need to clean and restructure
syswrap.
I came across the GENX/LINX stuff, and there must be XXX comments
stating that we should move it around later when we implement the
calls.
Regards,
kailash

Post by Peter Bex
Hai,
Last time I said that coregrind was updated.... It wasn't. Only the
directory structure had been update (ie all files that had been removed
from their tree were removed from our tree and all files that had been added
in their tree were added in our tree)
Now the coregrind files are /really/ updated. ;)
We need to take a good look at m_trampoline.S, since there have been
significant changes there. m_main.c has seen a lot of changes too.
m_ume.c was hacked a bit by Kailash, but it also has some updates, so I hope
I didn't fudge up anything you did, Kailash...
Also, the stuff in m_syswrap needs to be taken under consideration. Stuff
has changed a lot there and I'm not sure which is ours and which has been
updated in V. I do remember we hacked that quite a bit... especially
where GENX_/LINX_ is concerned, so I didn't change those diffs.
We should discuss this on IRC.
In general, I get the impression the code has become a little cleaner, many
direct number comparisons have been replaced by constants and such.
I think we have a real chance of getting this thing to work!
Greetz,
Peter
--
http://www.student.ru.nl/peter.bex
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth

[Kailash Sethuraman]

About VALGRINDLIB vs VALGRIND_LIB , it was my mistake, I had diffed a
header in the opposite direction, forgot to undo the changes resulting
from that in syswrap-generic. Thanks for fixing that peter.

Post by Kailash Sethuraman
IFor stuff in coregrind, if it compiles, its fine for now.
Syswrap stuff is taken care of, dont worry.
m_main is a big thing, I did it partially, but it still needs to be done.
The biggest changes on syswrap were cleanups on the trunk, now generic
is really generic etc. For the syscalls most of ourse are I_die_here
stubs anyway, we can move ours around later when we implement the
calls, as that is the time when we need to clean and restructure
syswrap.
I came across the GENX/LINX stuff, and there must be XXX comments
stating that we should move it around later when we implement the
calls.
Regards,
kailash

Post by Peter Bex
Hai,
Last time I said that coregrind was updated.... It wasn't. Only the
directory structure had been update (ie all files that had been removed
from their tree were removed from our tree and all files that had been added
in their tree were added in our tree)
Now the coregrind files are /really/ updated. ;)
We need to take a good look at m_trampoline.S, since there have been
significant changes there. m_main.c has seen a lot of changes too.
m_ume.c was hacked a bit by Kailash, but it also has some updates, so I hope
I didn't fudge up anything you did, Kailash...
Also, the stuff in m_syswrap needs to be taken under consideration. Stuff
has changed a lot there and I'm not sure which is ours and which has been
updated in V. I do remember we hacked that quite a bit... especially
where GENX_/LINX_ is concerned, so I didn't change those diffs.
We should discuss this on IRC.
In general, I get the impression the code has become a little cleaner, many
direct number comparisons have been replaced by constants and such.
I think we have a real chance of getting this thing to work!
Greetz,
Peter
--
http://www.student.ru.nl/peter.bex
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth

[Peter Bex]

Post by Kailash Sethuraman
About VALGRINDLIB vs VALGRIND_LIB , it was my mistake, I had diffed a
header in the opposite direction, forgot to undo the changes resulting
from that in syswrap-generic. Thanks for fixing that peter.

No prob, don't mention it ;)

[Kailash Sethuraman]

Commit 161 had the removal of some functionality from coredump-elf.c
This functionality was to functions to fill certain .NOTE sections
with valid data in a core dump.
The .NOTE sections however are still added.
The reasons to do this are : coredump-elf.c functionality in older
valgrinds were minimal, this functionality is new addition.
The sections to be filled in are linux specific. While similar
sections for netbsd exist, see /usr/include/elf.h, implementing this
functionality will mean that it cannot immediately be tested, unless
someone wants to write unit tests for it and check if dumps in the
correct format.
We dont have resources for that. Time/people.
Hence the functionality is removed , a big XXX comment has been added,
and it is left for later when valgrind runs enough to actually cause
the client to core dump.

Post by Peter Bex

Post by Kailash Sethuraman
About VALGRINDLIB vs VALGRIND_LIB , it was my mistake, I had diffed a
header in the opposite direction, forgot to undo the changes resulting
from that in syswrap-generic. Thanks for fixing that peter.

No prob, don't mention it ;)
--
http://www.student.ru.nl/peter.bex
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth

[Kailash Sethuraman]

As work on coregrind is more or less completed, the syncing work that
is, I imported the other directories from valgrind they are :
addrcheck
cachegrind
docs
helgrind
lackey
massif
memcheck
none
tests.

I dont know about the status of VEX
coregrind is where we have done most of our work, we have to basically
rewrite it :/

Regards,
Kailash

[Kailash Sethuraman]

I am disabling compilation of
auxprogs
tests
docs
for now.

Post by Kailash Sethuraman
As work on coregrind is more or less completed, the syncing work that
addrcheck
cachegrind
docs
helgrind
lackey
massif
memcheck
none
tests.
I dont know about the status of VEX
coregrind is where we have done most of our work, we have to basically
rewrite it :/
Regards,
Kailash

[Kailash Sethuraman]

The includes order in coregrind/launcher.c has been changed to work
around the problem of uid_t not being recognised int he config script,
it would be great if someone can fix it. Or ill look into it after
sync is complete.

Post by Kailash Sethuraman
I am disabling compilation of
auxprogs
tests
docs
for now.

Post by Kailash Sethuraman
As work on coregrind is more or less completed, the syncing work that
addrcheck
cachegrind
docs
helgrind
lackey
massif
memcheck
none
tests.
I dont know about the status of VEX
coregrind is where we have done most of our work, we have to basically
rewrite it :/
Regards,
Kailash

[Peter Bex]

The current state of Valgrind is such that it compiles entirely without
errors. Time to fix the code!

(mebbe we can have a look at enabling the stuff Kailash disabled; if it
is easy, it may just compile without any work on it)

Peter