|
From: Jeremy F. <je...@go...> - 2002-10-18 01:54:52
|
On Thu, 2002-10-17 at 16:47, Julian Seward wrote:
I haven't said much lately -- been v. busy having started a new job.
But thanks for your hacking (lest you think I don't appreciate it).
Some of this stuff may well diffuse into the code base when we have
time to do so.
Good. I was going to start pushing the smaller patches to you in chunks
to encourage merging.
I've been updating them as the CVS tree changes; the current snapshot is
always at http://www.goop.org/~jeremy/valgrind (its a couple of days
behind at the moment, but nothing major has happened since then).
I already put 03-poll-select and 04-lax-ioctls into 1.0.4 and will
merge the result to the head shortly. I considered 02-sysv-msg but
concluded it too risky for the stable branch
Why? Clearly nobody is using SYSV messaging in threaded programs
because it is currently completely broken. That patch makes it much
better (and might even be problem-free).
I'm also working on a patch to deal with open() blocking in the open of
a FIFO file. It is very ugly (attached for your amusement).
; I'll put it in the head.
That's fine.
I think 05 is already in the head (N put it in). I've looked at 00
and 01 and they seem possibilities for the head too.
I've been running them for a while without any problems (though I think
wider testing would do them good).
What does 06 do? I haven't heard talk of it.
They're just dead simple implementations of VG_(memset) and VG_(memcpy)
for vg_mylibc.c because I was missing them.
I also think vgprof is useful enough to put into the source as well.
There's the slight complexity of needing a modified gprof program to
interpret the results, but I'm looking into how to get my changes back
into binutils (or simply use kcachegrind as the display tool).
I'd like to branch off a 1.2.X (stable) branch from the head in the
near future (< 1 month, possibly less than that). It would be nice
to ship a half-decent Helgrind (race detector) in that, but I'm not
sure what the prospects for this are; do you have any views on that?
Not sure yet. I've been hacking on it a fair bit, but nothing I want to
show off yet. Mostly I've been working on making the reports more
useful so it is easier to tell what's real, what's noise and what's
completely spurious. At the moment the _dl_num_relocations update is
the most obvious source of noise; I think I'm getting spurious stuff
caused by thread stacks being in a strange state when they start up, but
I haven't confirmed that yet.
My current plans for it are:
- beef up reporting (starting by stealing chunks of memcheck)
- suppress duplicate errors
- investigate the state of the stack on thread startup
- make the memory granularity a compile-time setting for experiments
- implement the thread lifetime segment stuff (which may help with the
thread stack state problem; not sure yet)
I hope to make some substantial progress in the next week or so.
J
|