Add support for /proc/self/maps to Unikraft's Linux compatibility layer.

[Charles-Kaminski]

I've been experimenting with running applications compiled using Codon on Unikraft. My interest is in knowing if Codon on Unikraft is supportable.

I've successfully compiled and executed a Codon HTTP server using Unikraft's Linux binary compatibility layer. The server runs and handles HTTP requests, but I encountered a compatibility limitation involving the Boehm garbage collector embedded in Codon's runtime.

Boehm GC attempts to determine the main thread's stack boundaries using pthread_getattr_np(). However, this function fails in my Unikraft environment because glibc attempts to access /proc/self/maps, which is unavailable.

The application reports:

GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread

I reproduced the underlying issue independently of Codon using a small C diagnostic program:

pthread_getattr_np: 2 (No such file or directory)
getrlimit: 0 errno=0 (Success)
/proc/self/maps: unavailable errno=2 (No such file or directory)

Proposed Enhancement

Add support for /proc/self/maps to Unikraft's Linux compatibility layer.

The implementation would expose the process's memory mappings in the Linux-compatible /proc/self/maps format, including accurate stack mappings.

This would allow glibc and other Linux application runtimes to inspect memory mappings using an interface they already support.

Potential beneficiaries include:

• Garbage collectors such as Boehm GC that need to identify stack boundaries.
• Language runtimes that inspect process memory layouts.
• Debugging, profiling, and diagnostic tools that rely on /proc/self/maps.

This could also reduce the need for application-specific workarounds when running existing Linux binaries on Unikraft.

Environment

• Unikraft: 0.21.0~476b59c
• KraftKit: 0.12.16
• Runtime: unikraft.org/base:latest
• Architecture: x86_64
• Hypervisor: QEMU/KVM
• Codon: 0.20.3
• libc: Bundled glibc

I'd appreciate the team's thoughts on whether this enhancement would be worthwhile and how it might fit into Unikraft's development roadmap or if there's a workaround the project supports.

[arshajii]

Codon maintainer here - happy to help with this to the extent that we can. Seems like the proposed technical direction is relatively independent of Codon itself, but please let us know if there's anything we can do on our end to facilitate this.