Symbolication is broken when running a 32-bit userspace (and bpftrace binary) on a 64-bit kernel

[jeez]

Symbolication is broken on platforms running a 64-bit kernel but 32-bit userspace. For example, this is a simple test case that can reproduce the issue: $ bpftrace -e 'profile:hz:99 { @[kstack] = count(); }'

I believe this is happening because bpftrace requests uint64_t addresses to the kernel here https://github.com/iovisor/bpftrace/blob/fb77dae0b0a3d16b9453264401ff778556028576/src/bpftrace.cpp#L1941 but then performs an implicitly conversion to uintptr_t here https://github.com/iovisor/bpftrace/blob/fb77dae0b0a3d16b9453264401ff778556028576/src/bpftrace.cpp#L2076 .

Since bpftrace is a 32-bit binary in this case, then uintptr_t is only 32-bit wide and the higher part of the 64-bit address provided by the kernel is dropped / ignored. This leads to a failure when bcc_symcache_resolve() is called. The implicit conversion should have been flagged by the compiler, but -Wconversion is currently not used by bpftrace: https://github.com/iovisor/bpftrace/blob/79c366d3d3eb93da18b1e75fbe150b0537626ca8/CMakeLists.txt#L70 .

The issue can be fixed if we change resolve_ksym() so it receives an uint64_t addr instead, but I wanted to check here first if there is an alternate preferred solution in case I'm missing something. I've only tested and observed this with kernel symbols so far, but I see uintptr_t being used in other locations throughout the project so this might be an issue for a few other use cases too.

Let me know what you think, please.

bpftrace --info output

$ ./bpftrace --info
System
  OS: Linux 5.15.119-android13
  Arch: armv8l

Build
  version: v0.18.1
  LLVM: 14.0.6
  unsafe probe: yes
  bfd: no
  libdw (DWARF support): no

Kernel helpers
  probe_read: yes
  probe_read_str: yes
  probe_read_user: yes
  probe_read_user_str: yes
  probe_read_kernel: yes
  probe_read_kernel_str: yes
  get_current_cgroup_id: yes
  send_signal: yes
  override_return: no
  get_boot_ns: yes
  dpath: no
  skboutput: no

Kernel features
  Instruction limit: 1000000
  Loop support: yes
  btf: yes
  module btf: yes
  map batch: yes
  uprobe refcount (depends on Build:bcc bpf_attach_uprobe refcount): yes

Map types
  hash: yes
  percpu hash: yes
  array: yes
  percpu array: yes
  stack_trace: yes
  perf_event_array: yes

Probe types
  kprobe: yes
  tracepoint: yes
  perf_event: yes
  kfunc: no
  iter:task: no
  iter:task_file: no
  iter:task_vma: no
  kprobe_multi: no
  raw_tp_special: yes

[danobi]

A u64 for the addr seems reasonable. Did making that change fix the issue?

[jeez]

A u64 for the addr seems reasonable. Did making that change fix the issue?

Yes it does, as I mentioned above. I will send out a PR then. thanks