Yes, you are correct.  We only support one anonymous segment per tgid and we return the offset within the mapping instead of the offset within the binary.  We have almost finished working on all of the old suggestions and hope they will still be compatible with the changes you are making to fix this problem.


WBI Performance II
IBM Corp, Austin, TX
Reply to:
Phone:  (512) 838-4758, T/L:  678-4758

John Levon <> wrote on 04/24/2005 05:04:05 AM:

> On Sun, Apr 24, 2005 at 01:11:07AM +0100, John Levon wrote:
> > I'm starting to look at generic anon mapping support, and noticed what
> > appears to be a serious problem with your approach.
> I've started work on the BRANCH_ANON_MAPPING branch of oprofile. So far
> I've got it hacked up so that it will produce meaningful symbols output
> for anonymous regions.
> It hopefully doesn't look too bad. Basic principle: one sample file per
> anonymous mapping, e.g.:
> ./current/{root}/usr/X11R6/bin/XFree86/{dep}/{anon}/2234.0x81ee000.
> 0x8d7e000/CPU_CLK_UNHALTED.100000.0.all.all.all
> this is pid.start.end mangled. Entries in the file are stored as offsets
> from the start of the mapping. We mark start/end in the sample file
> header.
> When it comes to processing the sample file, we look in the header for
> the start address. If it's non-zero (IOW, an anon sample file) then we
> look for a section in the binary (see below) that has a VMA equal to
> that start address, and use the filepos of that section to fix up the
> sample file's entries from mapping offsets to file offsets.
> The binary: when demangling the above sample file, we look for a
> matching
> ./current/{anon}/usr/X11R6/bin/Xfree86-2234
> and if that binary exists, we force the app and lib image of that parsed
> sample file name to refer to that binary. Thus, if we've generated an
> ELF file for a, say, Java binary, it'll turn up as we'd expect in the
> output. Equally, if there isn't one, we get:
>    421235 25.6856 XFree86
>         CPU_CLK_UNHALT...|
>           samples|      %|
>         ------------------
>            331123 78.6077 anon (tgid:2234 range:0x81ee000-0x8d7e000)
>             90112 21.3923 XFree86
> which is exactly what you need.
> AFAICS, to support Java now, all that needs to be done is to implement
> libagent, plus the JIT user of it. This would ideally talk to oprofiled
> over a socket or whatever, so that the anon file mapping handling can be
> in one place rather than doing it twice.
> (No idea if anyone is still there or listening, but hey...)
> john