|
From: Nicholas N. <nj...@ca...> - 2004-07-02 12:55:59
|
Hi, People complain when Memcheck gives them useless error leak messages because the leaks occur in a .so which has been unmapped. Cachegrind has a similar problems -- all stats for an unmapped .so file get dumped into a single "discarded" pile, and cannot be used for annotation. The underlying problem is that we are using an instruction's address as the key for identifying it. This only works while the code is in memory; once it gets unloaded we can't rely on it any more. A better way of identifying instructions is with a (obj_file, obj_offset) pair. That will AFAICT uniquely identify any static instruction. It's not good for dynamically generated instructions -- I don't see how these can be uniquely identified without bringing time into the equation and that would be pretty awful -- but that probably doesn't matter because they don't have any debug info anyway, and so can be lumped together in an "other" category. If ExeContexts were changed to use (obj_file, obj_offset) pairs instead of just instructions, Memcheck (or the core) could, when printing the leaks, reload the debug info of any obj_file that had been unmapped. A similar thing could be done with Cachegrind to avoid the "discarded" pile, and it might actually make Cachegrind simpler overall. Anyway, I'm just thinking aloud. N |