|
From: Nicholas N. <nj...@cs...> - 2005-02-17 03:23:42
|
Hi, I've been removing some old junk from the code base. Here's some things I wasn't sure about removing: - FAQ 3.4 -- is that still needed? - README_PACKAGERS -- the stuff about stripping, is that still true/correct? - vg_intercepts.c -- does that still need to be generated from vg_intercept.c.base? I don't think so. Correspondingly, I think that comment about the "gory details" is no longer true. Does vg_replace_malloc.c still need this preprocessing, and the use of VG_INTERCEPT? (I really don't understand all that stuff, still.) - Section 2.8 of the manual talks about support for threads. It's out of date, I think it should be nuked. Anyone disagree? - I thought VG_USERREQ__MALLOC and all its associates (eg. VG_(sk_malloc_called_by_scheduler)) could be removed, but Jeremy, you've just started using them again in your latest commit. That's a shame, they're ugly. N |
|
From: Jeremy F. <je...@go...> - 2005-02-17 07:01:22
|
Nicholas Nethercote wrote:
> Hi,
>
> I've been removing some old junk from the code base. Here's some
> things I wasn't sure about removing:
>
> - FAQ 3.4 -- is that still needed?
Nope.
> - README_PACKAGERS -- the stuff about stripping, is that still
> true/correct?
Hm, not sure.
> - vg_intercepts.c -- does that still need to be generated from
> vg_intercept.c.base? I don't think so. Correspondingly, I think that
> comment about the "gory details" is no longer true.
All the intercepts are gone, so no.
> Does vg_replace_malloc.c still need this preprocessing, and
> the use of VG_INTERCEPT?
> (I really don't understand all that stuff, still.)
Yes; we still need to intercept all the malloc functions. All this
stuff is to make sure we intercept the allocators before they get called.
> - Section 2.8 of the manual talks about support for threads. It's out of
> date, I think it should be nuked. Anyone disagree?
Hm, some of it is still true, but a lot of the details are wrong.
> - I thought VG_USERREQ__MALLOC and all its associates (eg.
> VG_(sk_malloc_called_by_scheduler)) could be removed, but Jeremy,
> you've
> just started using them again in your latest commit. That's a shame,
> they're ugly.
Well, we could lose VG_(sk_malloc_called_by_scheduler) I think.
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-19 01:37:05
|
On Wed, 16 Feb 2005, Jeremy Fitzhardinge wrote: >> - Section 2.8 of the manual talks about support for threads. It's out of >> date, I think it should be nuked. Anyone disagree? > > Hm, some of it is still true, but a lot of the details are wrong. I've cut it down a lot. I'm not sure if the numbers for the round-robin scheduling are still right. N |