I noticed while exploring the ARC++ container via /proc/<tid>/root that absolute symlinks may confuse quipper reading DSOs inside containers.

When resolving an absolute symlink, the kernel will go back to the current task's root. For example, /etc is a symlink to /system/etc, so accessing /proc/<tid>/root/etc will try to access /system/etc, not /proc/<tid>/root/system/etc, and so the correct file will not be found.

However, there's also the possibility that perf will emit mmap records with symlinks already fully and correctly resolved to absolute paths (it does resolve chroots--but not mount namespaces), so check that before trying to solve this issue.

The command below shows a list of absolute symlinks in the ARC++ container. Some of them are indeed DSOs that we could get samples in.

localhost / # find /opt/google/containers/android/rootfs/root -lname '/*' -printf '%P -> %l\n'
charger -> /sbin/healthd
d -> /sys/kernel/debug
etc -> /system/etc
sdcard -> /storage/self/primary
system/app/Bluetooth/lib/arm/libbluetooth_jni.so -> /system/lib/libbluetooth_jni.so
system/app/Camera2/lib/arm/libjni_jpegutil.so -> /system/lib/libjni_jpegutil.so
system/app/Camera2/lib/arm/libjni_tinyplanet.so -> /system/lib/libjni_tinyplanet.so
system/app/PrintSpooler/lib/arm/libprintspooler_jni.so -> /system/lib/libprintspooler_jni.so
system/etc/media_codecs.xml -> /vendor/etc/media_codecs.xml
system/etc/media_codecs_performance.xml -> /vendor/etc/media_codecs_performance.xml
system/priv-app/DefaultContainerService/lib/arm/libdefcontainer_jni.so -> /system/lib/libdefcontainer_jni.so
system/vendor -> /vendor