Discussion:
Merge with current and plans
Kailash Sethuraman
2005-11-24 12:49:11 UTC
Permalink
Hi guys,

I think its fair to say that after some period of no work at all, we
are atleast doing something these days. I merged in syswrap-generic.c
, however it would be good if one of you could take a look at our
syswrap-generic vs the one in valgrind's trunk to ensure that I have
not broken anything, in terms of our own netbsd specificness as well
as possibly missed merges.
It is not in a state where it compiles yet. I suspect other files will
need to be merged as well.
Peter do you have any idea on what these might be? Perhaps a list of
files that need to be merged?
Then we can get on it, get valgrind compiling. I think this merge will
provide us with nullgrind, so we dont have to deal with memcheck
injecting heavy instrumentation code. We can deal with a program
simply running under valgrind first.
We should do more regular/quick merges, now that we have discovered
how easy it is with edfiff.
What do you guys think?
Regards,
Kailash
Peter Bex
2005-11-24 13:45:55 UTC
Permalink
Post by Kailash Sethuraman
Hi guys,
I think its fair to say that after some period of no work at all, we
are atleast doing something these days. I merged in syswrap-generic.c
, however it would be good if one of you could take a look at our
syswrap-generic vs the one in valgrind's trunk to ensure that I have
not broken anything, in terms of our own netbsd specificness as well
as possibly missed merges.
It looks good to me, after a quick browse through it with ediff.
Post by Kailash Sethuraman
It is not in a state where it compiles yet. I suspect other files will
need to be merged as well.
Peter do you have any idea on what these might be? Perhaps a list of
files that need to be merged?
I'd almost say "everything". Either that, or just try to compile and see
what breaks ;)
(I expect every file to be needing at least some modifications, anyway)
Post by Kailash Sethuraman
Then we can get on it, get valgrind compiling. I think this merge will
provide us with nullgrind, so we dont have to deal with memcheck
injecting heavy instrumentation code. We can deal with a program
simply running under valgrind first.
Let's hope so!
Post by Kailash Sethuraman
We should do more regular/quick merges, now that we have discovered
how easy it is with edfiff.
What do you guys think?
I disagree. It only distracts us from what really needs to be done; getting
the fucker to compile and run under NetBSD.
Perhaps when we are in that stage, we can update once more and then ask
for our code to be integrated in mainline.

Then, hopefully we can get commit access to the main repos and gradually
work our way to full syscall implementations. (we don't need to implement
all syscalls to get it working on NetBSD, so let's not focus on that).

Regards,
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
2005-11-24 13:56:58 UTC
Permalink
Hmm,
I think compiling to spot the required change will be a bit arduous.
Especially when we go hunting for the change that needs to be made.
Perhaps we should try some other approach. Diffing module by module
within coregrind perhaps?
Post by Peter Bex
Post by Kailash Sethuraman
Hi guys,
I think its fair to say that after some period of no work at all, we
are atleast doing something these days. I merged in syswrap-generic.c
, however it would be good if one of you could take a look at our
syswrap-generic vs the one in valgrind's trunk to ensure that I have
not broken anything, in terms of our own netbsd specificness as well
as possibly missed merges.
It looks good to me, after a quick browse through it with ediff.
Post by Kailash Sethuraman
It is not in a state where it compiles yet. I suspect other files will
need to be merged as well.
Peter do you have any idea on what these might be? Perhaps a list of
files that need to be merged?
I'd almost say "everything". Either that, or just try to compile and see
what breaks ;)
(I expect every file to be needing at least some modifications, anyway)
Post by Kailash Sethuraman
Then we can get on it, get valgrind compiling. I think this merge will
provide us with nullgrind, so we dont have to deal with memcheck
injecting heavy instrumentation code. We can deal with a program
simply running under valgrind first.
Let's hope so!
Post by Kailash Sethuraman
We should do more regular/quick merges, now that we have discovered
how easy it is with edfiff.
What do you guys think?
I disagree. It only distracts us from what really needs to be done; getting
the fucker to compile and run under NetBSD.
Perhaps when we are in that stage, we can update once more and then ask
for our code to be integrated in mainline.
Then, hopefully we can get commit access to the main repos and gradually
work our way to full syscall implementations. (we don't need to implement
all syscalls to get it working on NetBSD, so let's not focus on that).
Regards,
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
2005-11-24 14:10:46 UTC
Permalink
Post by Kailash Sethuraman
Hmm,
I think compiling to spot the required change will be a bit arduous.
Especially when we go hunting for the change that needs to be made.
Perhaps we should try some other approach. Diffing module by module
within coregrind perhaps?
That's what I meant with "everything". Shouldn't we update the other
parts too? (ie, the other subdirs of valgrind besides coregrind)
Yes ,but as we have not done much work on these, It should be straightforward.

Regards,
Kailash
Eric Auge
2005-12-06 22:26:39 UTC
Permalink
Hmm lets have it running first, befre making plans,
my 2 cents
Eric.
Post by Kailash Sethuraman
Post by Kailash Sethuraman
Hmm,
I think compiling to spot the required change will be a bit arduous.
Especially when we go hunting for the change that needs to be made.
Perhaps we should try some other approach. Diffing module by module
within coregrind perhaps?
That's what I meant with "everything". Shouldn't we update the other
parts too? (ie, the other subdirs of valgrind besides coregrind)
Yes ,but as we have not done much work on these, It should be straightforward.
Regards,
Kailash
Peter Bex
2005-11-24 14:08:21 UTC
Permalink
Post by Kailash Sethuraman
Hmm,
I think compiling to spot the required change will be a bit arduous.
Especially when we go hunting for the change that needs to be made.
Perhaps we should try some other approach. Diffing module by module
within coregrind perhaps?
That's what I meant with "everything". Shouldn't we update the other
parts too? (ie, the other subdirs of valgrind besides coregrind)

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
Loading...