|
From: Julian S. <js...@ac...> - 2002-11-16 11:11:43
|
Jeremy
3 more went in:
30-hg-fix
43-nonblock-readwritev
Does this duplicate wait_for_fd_to_be_writable_or_erring? it seems to be
added by the patch and I'm sure that function exists already somewhere.
27-nvalgrind
Small request: could you possibly not reuse the sequence numbers, ever? It's
confusing, and having a unique sequence is kinda useful in .. well, knowing
the order in which the patches notionally exist. Thanks.
I'm documentation hacking again this weekend. Is there any progress on the
helgrind docs? That would be nice :-)
J
|
|
From: Jeremy F. <je...@go...> - 2002-11-16 17:59:18
|
On Sat, 2002-11-16 at 03:18, Julian Seward wrote:
> 43-nonblock-readwritev
> Does this duplicate wait_for_fd_to_be_writable_or_erring? it seems to be
> added by the patch and I'm sure that function exists already somewhere.
I looked around, but didn't see it. I was a bit surprised too.
> 27-nvalgrind
>
> Small request: could you possibly not reuse the sequence numbers, ever? It's
> confusing, and having a unique sequence is kinda useful in .. well, knowing
> the order in which the patches notionally exist. Thanks.
OK. The main reason is that its a little cumbersome for me to rename
patches, but that shouldn't be too hard to fix.
Also, I think I'll take you up on CVS access now that things are
beginning to settle down a bit.
> I'm documentation hacking again this weekend. Is there any progress on the
> helgrind docs? That would be nice :-)
No, I'm still working on symbolic addresses. It seems to work well for
my small test programs, but less often for big code. I'm still trying
to work out why, but I think it's because the compiler will see a
definition like:
struct foo {
struct bar *thing;
};
struct bar {
...
}
and generate an undefined reference to struct bar for foo.thing rather
than a reference to the full structural definition which follows.
But an example of when it does work:
==19268== Thread 3:
==19268== Possible data race writing variable at 0x8049A60 (g.0+8)
==19268== ...
==19268== Address 0x8049A60 is &(globals[4]->glob2) at mutex.c:50
I think it is close enough to be merged in as a somewhat experimental,
incomplete feature with a clo with defaults to off. Before that, I want
to split the stabs and DWARF2-specific parts of vg_symtab2.c into
separate files, because its becoming a bit unwieldy at the moment.
J
|