[memleak/dotnet] No symbols on libcoreclr.so (dotnet 6.0.4)

I am trying to debug a dotnet program in k8s.

- Dotnet version 6.0.5
- EC2 node @ 5.4.226-129.415.amzn2.x86_64
- docker app base image @ mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim
- debugging sidecar base image @ [docker-hub.sandstorm.de/public-containers/ebpf-tracer:latest](https://gitlab.sandstorm.de/public-containers/ebpf-tracer)

I have a pod with host pid enabled, where I have the main app container and a sidecar running in privileged mode, sharing the `/tmp` folder with the host in order for the debugging container (where memleak is being run) to be able to see the `/tmp/perf-{PID}.map ` file in the target pod.

I also download the debugging symbols for dotnet and placed them at `/usr/lib/debug/usr/share/dotnet/shared/Microsoft.NETCore.App/$DOTNET_VERSION/` in the target pod witht the dotnet application

Unfortunately, the memleak script is not resolving symbols from neither `libcoreclr.so` and `libclrjit.so`, despite me having those debug symbols in the mentioned folder (I am not sharing the target container filesystem with the debug container, so the memleak script is not aware of these debug files, only the dotnet process in the app container).

Having said that, I want to know:

- Is this expected behavior, and symbol resolution from these dotnet libs are unsupported?
- If the symbols should have been resolved, what are the requirements for the memleak tool to resolve them?

Begin with the memleak tool's symbol-resolution behavior in the privileged debugging sidecar, using the listed .NET 6 containers and shared /tmp setup. Verify whether libcoreclr.so and libclrjit.so symbols are visible from the debugging container; done means documenting the supported behavior and requirements, or confirming a reproducible resolution fix.

Written by the indexing model from the issue text.