Re: [Valgrind-developers] co-operating as module loader with other tools

[John R. <jr...@Bi...>]

Nicholas Nethercote wrote:
> John, will generated code be covered by this profile?

Runtime-generated code will be counted as if it were inlined
into the nearest code [in calling stack order] that was subject
to execve() or dlopen().  If runtime-generated code can be described
as a ELF module that the profiler finds out about via intercepting
(*_r_debug.r_brk)(), then runtime-generated code also will be profiled.

  I see this entry:
> 
>        1     994533995     497.2670     497.2670  10 [9] 2:0x70057c53
>        1             0       0.0000       0.0000     0 [9] 2:0x70057c53
> (self)
> 
> Is this a generated basic block?

No, it's a subroutine whose name could not be found.  There was a CALL
to that address, but no dynamic symbol, static symbol, or debug symbol
had that address.  [Or, perhaps it's a profiler bug. :-)]

> 
> Also, Valgrind seg faulted during the run -- is this due to a bad
> interaction with tsprof?

It was the profiler that segfaulted: a bug in profiling syscall
__NR_exit or __NR_exit_group.  Subroutines that have not exited
must be "shut down."  Fixed in current version.


As for profiling a longer-running program, please suggest suitable
testcases.

-- 
John Reiser, jr...@Bi...