|
From: David M. <dm...@gm...> - 2005-12-23 09:48:04
|
Hi again, Here are a few more questions - any help appreciated. 1) We've noticed as per the FAQ that a statically linked malloc() is not intercepted by valgrind and so not available to memcheck. Has anyone looked at a tool or a techniques that could intercept statically linked malloc() and friends by detecting them during instrumentation? 2) Are there any problems known with linking C++ code into a tool that we should be careful to avoid? 3) Is there any easy way to intercept stack frame creation and destruction on IA32? (I suspect the answer is no, given the FAQ talks about how Valgrin= d doesn't check arrays on the stack, but I'd like to ask). Given a memory address, is there a way to determine which thread stack and stack frame it belongs to? Thanks again, -David Molnar |
|
From: Ivan S. <isj...@i1...> - 2005-12-23 13:19:46
|
On Friday 23 December 2005 10:47, David Molnar wrote: > 1) We've noticed as per the FAQ that a statically linked malloc() is not > intercepted by valgrind and so not available to memcheck. Has anyone looked > at a tool or a techniques that could intercept statically linked malloc() > and friends by detecting them during instrumentation? If the program calls brk() or sbrk() then memcheck should probably issue a warning that the program has probably implemented its own heap management. Of course, a program could also implement its own heap with mmap(). |
|
From: Nicholas N. <nj...@cs...> - 2005-12-23 22:24:51
|
On Fri, 23 Dec 2005, David Molnar wrote: > 1) We've noticed as per the FAQ that a statically linked malloc() is not > intercepted by valgrind and so not available to memcheck. Has anyone looked > at a tool or a techniques that could intercept statically linked malloc() > and friends by detecting them during instrumentation? Not that I know of. > 2) Are there any problems known with linking C++ code into a tool that we > should be careful to avoid? No idea. Probably. 3.1.0 does not link with glibc at all, I can imagine there might be problems with C++ code wanting to use glibc allocators. > 3) Is there any easy way to intercept stack frame creation and destruction > on IA32? Not that I know of, but it can certainly detect when the SP changes. > (I suspect the answer is no, given the FAQ talks about how Valgrind > doesn't check arrays on the stack, but I'd like to ask). > Given a memory > address, is there a way to determine which thread stack and stack frame it > belongs to? Yes, see describe_addr() in memcheck/mac_shared.c. Nick |
> 1) We've noticed as per the FAQ that a statically linked malloc() is not
> intercepted by valgrind and so not available to memcheck. Has anyone looked
> at a tool or a techniques that could intercept statically linked malloc()
> and friends by detecting them during instrumentation?
Valgrind intercepts malloc/free/etc using the [runtime] dynamic linking
mechanism. If the [build time] static linking symbol table still is
available (has not been stripped), then there is no particular reason
why additional routines could not be intercepted, given enough effort.
Detecting malloc/free/etc behaviorally (by looking at the sequence of
executed opcodes, addressing modes, etc.) probably is "impossible."
> 2) Are there any problems known with linking C++ code into a tool that we
> should be careful to avoid?
Prevent the tool's libraries from colliding with those used by the program
being instrumented. Among other things, you must be intimately familiar
with the relocation operations (Elf32_Rel) of the machine. Also,
the threading and thread-local storage ("TLS") assumptions that are
builtin with recent glibc and ld-linux probably will give you a hard time.
> 3) Is there any easy way to intercept stack frame creation and destruction
> on IA32?
No. The C compiler has too many choices, and hand coders have even more
(CALL and PUSH can be used solely for their side effects of allocating
one word of stack space.) And what do you call alloca()?
--
|
|
From: Julian S. <js...@ac...> - 2005-12-23 23:23:18
|
> 1) We've noticed as per the FAQ that a statically linked malloc() is not > intercepted by valgrind and so not available to memcheck. There's no reason in principle that statically linked mallocs couldn't be intercepted. The reason the current (>= 3.1.0) intercept machinery can't do that is due to a nasty kludge in it, not for any fundamental reason. I've rewritten it from scratch (currently in branches/FNWRAP) and that should be able to handle intercepting in static binaries, providing only that there is a visible symbol table entry for the function to be intercepted. I am hoping to merge FNWRAP with the trunk some time in January. > 2) Are there any problems known with linking C++ code into a tool that we > should be careful to avoid? In 3.1.0 and after, we are completely independent of glibc, for reasons of portability and stability. (It's a great simplication!) Unfortunately that means that realistically you have no chance of using C++, at least not without a great deal of tearing your hair out. Even using C, you are limited to using the support functions defined in pub_tool_libc*.h. Attempts to subvert that by (eg) #include <stdlib.h> will end up in a link failure. Generally studying the standard tool sources (lackey/cachegrind/massif/ memcheck) is a good starting point. > 3) Is there any easy way to intercept stack frame creation and destruction > on IA32? As John Reiser says, basically no. Josef Wiedendorfer's callgrind tool does mostly succeed in doing so, but at the cost of a number of heroic hacks that only Josef understands :-) J |