|
From: Nicholas N. <nj...@cs...> - 2005-06-28 13:14:44
|
Hi, I basically like this idea. The things I'm unsure about are below. > - External tools: installing eg Callgrind could be more complex as it > would have to be linked against libcoregrind.a at > installation time, even if installing from RPMs. This is important, lots of people use Callgrind so we want to make it possible to do this. > - PIE: this would make PIE'd valgrinds impossible. I'm not too > bothered since it seems like the main use for pie is to work > around the current address-space-layout inflexibilities, which > are up for review anyway. I'd be happier with ditching this once the address-space reworking has been done and shown to work. > - Need a replacement driver: since only one tool at a time is > linked into libcoregrind.a, the --tool= flag is ignored, and so > we'd need a new ultra-trivial driver which inspects that flag > and selects the right executable to start. > > Alternatively, adjust the core/tool interface so that multiple > tools can be linked into the core all at once. This sounds > attractive, and could save disk space. After recent changes to the 3.0 this is much closer to possible, since we're not using predefined names (eg. SK_(instrument)()) for everything. But it doesn't sound like it would play well with external tools. > Comments? In particular, are there other bad consequences I haven't > thought of? Also, [GregP] how would this play for making V work > for MacOS ? I assume the LD_PRELOAD modules (eg. vg_preload_core.so, vgpreload_memcheck.so) are still being used correctly? They must be if you say Memcheck is working properly. N |