|
From: Jeremy F. <je...@go...> - 2005-02-24 02:30:24
|
Nicholas Nethercote wrote:
> Seems reasonable, except that you've put lots of the code into the
> core. The leak checker is currently entirely within Memcheck
> (Addrcheck shares some of that code), and I think this distinction
> should be maintained.
The leak checker is entirely within memcheck, and is completely shared
with addrcheck. I added a couple of helper calls so that the
leakchecker can get information from the core about where mapped memory
is, and what the contents of each thread's registers are. Neither call
is arch-specific (though obviously fetching the register values has an
arch-specific component).
And I can't bring myself to see 44 lines of simple code as "lots".
> So eg. the code added in coregrind/x86/state.c should instead be in
> memcheck/x86/<something.c> (which currently doesn't exist). Or you
> could add an arch-specific function that returns some kind of GP
> register list, which would save you from having arch-specific code in
> Memcheck.
I guess. The code added to the core is pretty small and simple, and it
doesn't add any more arch-dependencies to memcheck. There's no existing
interface for a tool to get a thread's register state, so there would
need to be some extension to the tool interface anyway; I went for the
minimal change to get the job done. I prefer the callback approach to
passing around arrays, because it doesn't expose the representation of
the arch registers (since it only needs to look at general-purpose
registers which might possibly hold pointers, which might not be
contigious in memory for a particular architecture).
J
|