Re: DSO_BINARY_TYPE__SYSTEM_PATH_DSO

[Ian Rogers <irogers@google.com>]

On Fri, May 19, 2023 at 10:49 AM Rajasekhar Pulluru
<pullururajasekhar@gmail.com> wrote:
>
> Hi Team,
> Could someone help me shed some light on this macro
> DSO_BINARY_TYPE__SYSTEM_PATH_DSO ?
>
> Case-1: I am trying to run perf top -p `pidof <app>` on ubuntu host
> (based on ubuntu:jammy, outside the container) where the <app> runs
> inside a container that's based on ubuntu bionic, and I don't see any
> of <app> symbols (only hex-address and no function names) in perf top
> output.
>
> Case-2: When I try to run perf top -p `pidof <app>` on ubuntu host
> (based on ubuntu:bionic, outside the container) where the <app> runs
> inside a container that's also based on ubuntu bionic, and I can see
> <app> symbols (function names) in perf top output.
>
> On debugging both the cases, I find that, case-2 is able to display
> symbol when dso__load of </opt/bin/<app> is successful for the type
> DSO_BINARY_TYPE__SYSTEM_PATH_DSO, where-as the same fails for case-1
> (is_regular_file check fails), and perf top reports "Failed to open
> /opt/bin/<app>, continuing without symbols".
>
> In both the cases, the file /opt/bin/<app> is not available on the
> host, and its only available inside the container.
> What could be causing the above failure?
>
> Appreciate any help/inputs.

Hi Rajasekhar,

This is an area I'm not familiar with. I suspect the reason perf
record/report are succeeding from your description is namespace
information. If you look at the perf.data file with "perf script" and
probably the "-D" option, you should see information. I'm not sure
anybody has wired up the namespace code with perf top, which would go
a long way to explaining your problems.

Thanks for investigating this!
Ian

> Thanks & Regards,
> Rajasekhar