From what I can see, all those are memory debugging tools, not really profiling tools - which is what I really need. For some reason, gprof (despite built-in compiler support) is just reporting the call stack of various functions dead wrong - and it's not a complicated case such as some function calling a system function that hasn't been compiled for profiling, it's mis-reporting one function as calling another directly when it quite clearly is doing no such thing.

I'll have to try a couple other systems (we've got an HPUX and an AIX system and can get access to a Linux system), but it's annoying when a (supposedly) "standard" Unix tool, supposedly supported by the vendor, doesn't work.

And, Ben, I can do things with macros if I must, but it's also annoying to have to hand-instrument code with printf's (or however I go about it) when I shouldn't have to.

The function call HPUX 11.x claims is being called *is* actually in the program, but I can set a breakpoint in the program compiled for debugging and very clearly see it's being called from a completely different "known" function. The only thing I can think is that HP's implementation is totally mis-reading the call stack, or the compiler is (for some reason) inserting the wrong profiling instrumentation, or something like that.

It does seem to work much better under AIX 4.3, but still not perfectly - but in this case the weird function call is truly an unknown call, and in *this* case I can believe it may well be a system call inserted by the compiler implementing some sort of profiling statistical monitoring function. It otherwise does seem to give a more accurate call stack, although working under AIX is (usually) more painful than working under HPUX. Fer crying out loud, AIX still comes with dbx. Even HP eventually adopted gdb, contributing a terminal interface, rather than trying to maintain xdb or dde.