Fix symbol resolution across mount namespaces (#2029)

[vijunag]

• Symbol lookup fails when the process is running on a different namespace.
• ProcSyms already has the capability to switch mount namespaces to resolve symbols.
• Identified bug where the BPF doesn't migrate to process mount namespace before opening the symbol files and fails to locate the file.
• Patch makes sure that 'ProcMountNSGuard g(ps->mount_ns_instance_.get())' is created every single time a text section for the process is loaded.
• Patch was tested by 1) creating docker container and running the process 2) running "bcc/tools/profile" script on the global PID namespace of the process

Test - Performed a test by running bcc/tools/profile on a PID running in a container and found the resolution to be working fine.
`#define _GNU_SOURCE
#include <link.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/auxv.h>
#include <string.h>

int len;
int baz()
{
int i=0;
char a[8192], b[8192];

label:
for(i=0;i<10000;++i) {
memcpy(a,b,len);
}

goto label;
}

int foo()
{
baz();
}

int bar()
{
foo();
}

int main(int argc, char **argv)
{
printf("Start profiling\n");
len=8192;
bar();
return 1;
}`

python profile -U -p 26966 1
Sampling at 49 Hertz of PID 26966 by user stack for 1 secs.
warning: JITed object file architecture unknown is not compatible with target architecture i386:x86-64.

[unknown]
foo
bar
main
__libc_start_main
-                sampleme (26966)
    1

baz
foo
bar
main
__libc_start_main
-                sampleme (26966)

[vijunag]

We have to move to mount namespace before accessing the file /proc/pid/exe file.

[vijunag]

Ditto. Migrate to task's mount namespace before accessing the symbol file.

[yonghong-song]

@tekumara could you check whether this fixed your issue (#1990)?
@palmtenor could you comment on the change as well?

[tekumara]

Using this PR, I run bcc inside a container to debug another container, and I don't get the warnings! Thank you! 🙇
However I still get [unknown]s in the stack trace (see below). Should these be resolved?

host $ sudo docker run -it --privileged   -v /sys/kernel/debug:/sys/kernel/debug:rw -v /lib/modules:/lib/modules:ro   -v /usr/src:/usr/src:ro   -v /etc/localtime:/etc/localtime:ro   --workdir /usr/share/bcc/tools   --pid=host   bcc
root@22de24248ccc:/usr/share/bcc/tools# /usr/share/bcc/tools/trace 'SyS_write (arg1==1) "%s", arg2' -U -p `pidof java`
PID     TID     COMM            FUNC             -
5573    27047   java            SyS_write        2018-11-05 12:33:05,094 [info] application-akka.actor.default-dispatche
        __GI___libc_write+0x2d [libpthread-2.24.so]
        [unknown] [libjava.so]
        Java_java_io_FileOutputStream_writeBytes+0x1a [libjava.so]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown]
        [unknown] [libjvm.so]
        [unknown] [libjvm.so]
        [unknown] [libjvm.so]
        [unknown] [libjvm.so]
        [unknown] [libjvm.so]
        [unknown] [libjvm.so]
        [unknown] [libjvm.so]
        start_thread+0xc4 [libpthread-2.24.so]

[vijunag]

@tekumara - You don't have to run bcc inside of a container. Can you try profiling the process using the default namespace pid and check if it works ?

[tekumara]

@vijunag do you mean running bcc from the host? I've tried running bcc (compiled with this PR) on the host (ie: not in a container) and it produces the same output as above.

[vijunag]

@tekumara - Are your Java shared objects compiled with frame pointers ? If no, then the problem is not related to this issue.

[tekumara]

@vijunag I've installed the jdk8 debug symbols into the container and now I'm not getting [unknown] [libjvm.so] or [unknown] [libjava.so] lines.

I've also created a java perf map and am now getting Interpreter+0x24f0 [perf-8.map] instead of [unknown]. After letting the JVM warmup and regenerating the perf map these become correct
java stack lines.

TL;DR - all good, thankyou!

[yonghong-song]

[buildbot, test this please]

[yonghong-song]

@palmtenor any opinion? Will this work for the case to trace a process running inside the container but user provided a host file path?

[palmtenor]

Yeah this LGTM. Thanks for the fix!