Resolve native symbols for containerized Python processes using the target process root (via /proc/<pid>/root)

[pramodk]

Is there an existing proposal for this?

• I have searched the existing proposals

Is your feature request related to a problem?

Yes.

When pystack remote --native <pid> attaches to a Python process running inside a container runtime such as
Enroot, Python frames can still be visible, but native C/C++ symbol resolution fail for shared
libraries whose mapped paths only exist inside the container filesystem.

A simplified example:

Python process:
  loads libnative_hello.so with ctypes

Inside container:
  /tmp/pystack-native-symbols-current/libnative_hello.so  => exists

Host running PyStack:
  /tmp/pystack-native-symbols-current/libnative_hello.so  => does not exist

The host can still see the target process mappings:

  grep libnative_hello.so /proc/<pid>/maps

  Example mapping:

  ... /tmp/pystack-native-symbols-current/libnative_hello.so

But resolving that path directly from the host fails:

  test -r /tmp/pystack-native-symbols-current/libnative_hello.so => not readable from host

The same file is reachable through the target process root:

  test -r /proc/<pid>/root/tmp/pystack-native-symbols-current/libnative_hello.so => readable

Describe the solution you'd like

When PyStack resolves native symbols for a live process, if opening a mapped ELF path from /proc/<pid>/maps fails, retry the lookup through the target process root /proc/<pid>/root/<mapped-path>.

For example, if /proc/<pid>/maps contains:

  /tmp/pystack-native-symbols-current/libnative_hello.so

and the host cannot open that path directly, PyStack should try:

  /proc/<pid>/root/tmp/pystack-native-symbols-current/libnative_hello.so

This would allow PyStack to resolve native symbols for libraries that are visible to the target process but not directly visible in the host filesystem namespace.

The fallback should only be used when direct path lookup fails, so normal host behavior remains unchanged.

Alternatives you considered

1. Require users to bind-mount container paths at the same location on the host.

This works in some controlled cases, but not feasible with the large container stack used today.

2. Ask users to run PyStack inside the same container.

This can work for simple cases, but it is not always compatible with attach workflows where the debugger/profiler
runs on the host or from a scheduler/tooling process outside the container