Migrate from objdump and grep to library calls

[acj]

Fixes #128.

[brendangregg]

Thanks!

I'd merge it but we need to figure out how to handle this:

[ 18%] Building CXX object src/CMakeFiles/bpftrace.dir/bpftrace.cpp.o
/home/bgregg/Build/bpftrace/src/bpftrace.cpp:19:10: fatal error: bcc_elf.h: No such file or directory
 #include "bcc_elf.h"
          ^~~~~~~~~~~

I guess I have an older bcc version installed.

[acj]

It looks like bcc_elf.h was separated from bcc_helpers.h around bcc 0.2 or so. I haven't been able to build that version locally, but hopefully the cmake workaround that I just pushed will work. I'm no cmake expert, though, so suggestions are welcome.

[brendangregg]

Now get:

/home/bgregg/Build/bpftrace/src/bpftrace.cpp:22:10: fatal error: bcc_helpers.h: No such file or directory
 #include "bcc_helpers.h"
          ^~~~~~~~~~~~~~~

[acj]

Hmm, okay. I'll investigate this more. What version of bcc do you have installed?

[acj]

This seems similar to the issue reported in this comment from #335, but I don't think it's a bcc version problem. The libbpfcc-dev package on Ubuntu 18.04 doesn't include bcc_elf.h despite its being present in bcc 0.5.0. The upstream Debian package has it, and the libbcc package from the iovisor apt repo also has it.

I can see the symbols in the library:

$ objdump -tT /usr/lib/x86_64-linux-gnu/libbcc.so.0.5.0 | grep bcc_elf
00000000004418f0 g    DF .text  0000000000000017  Base        bcc_elf_is_shared_obj
0000000000441700 g    DF .text  0000000000000131  Base        bcc_elf_foreach_load_section
00000000004418c0 g    DF .text  0000000000000028  Base        bcc_elf_is_exe
0000000000441440 g    DF .text  00000000000002ad  Base        bcc_elf_foreach_usdt
000000000232eea0 g    DF .text  000000000000013a  Base        _ZN4USDT7Context9add_probeEPKcPK12bcc_elf_usdt
0000000000441ae0 g    DF .text  00000000000000ac  Base        bcc_elf_foreach_vdso_sym
00000000004416f0 g    DF .text  0000000000000008  Base        bcc_elf_foreach_sym
0000000000441910 g    DF .text  0000000000000018  Base        bcc_elf_is_vdso
000000000232efe0 g    DF .text  0000000000000011  Base        _ZN4USDT7Context11_each_probeEPKcPK12bcc_elf_usdtPv
0000000000441840 g    DF .text  000000000000007c  Base        bcc_elf_get_type

How can we fix this? Should I open an issue on the bcc repo?

[acj]

@brendangregg ping. Any recommendations here?

[brendangregg]

I need to setup a fresh environment and retest to see if it was just a problem with my dev environment (my dev environments get messy since I'm always building and testing things).

[acj]

I ended up doing the same. It was working for me on Ubuntu 16.04, but I ran into the missing header issue on 18.04. Seems like a bug with the libbpfcc-dev package.

[mmarchini]

@acj it should be working now with bcc master. I'm just not sure we want to land this before bcc makes a new release.

Also, should we try to keep it backwards compatible (keep using objdump for older bcc versions)?

[mmarchini]

I would like to merge this since it will bring a big improvement on startup time once #557 is merged as well.

[acj]

Sorry for the delay. Great to hear about the startup time improvements!

I'll test this against bcc master tomorrow morning.

If we want to merge soon, then I agree that backwards compatibility is a good move. Do we have a reliable way to get the installed bcc version? If not, I can probably branch based on the presence of bcc_elf.h.

[mmarchini]

We tend to use feature detection for compatibility with multiple bcc versions. Here's one example: c03c39f

[mmarchini]

LGTM

[brendangregg]

Looks good, thanks!