`/proc/self/stat` reports startstack as 0 that breaking stack discovery

[doanbaotrung]

Summary

/proc/self/stat reports field 28, startstack, as 0.

Some Linux runtimes and crash/unwind paths read /proc/self/stat field 28, then look up that address in /proc/self/maps to identify the process stack VMA. Under elfuse, that lookup fails because address 0 is not inside any stack mapping, even though /proc/self/maps correctly contains a [stack] entry.

Observed Behavior

/proc/self/maps contains a stack VMA, for example:

7801000-8000000 rw-p 00000000 00:00 0    [stack]

But /proc/self/stat emits zeros for startcode, endcode, and startstack:

field 25 rsslim     = 18446744073709551615
field 26 startcode  = 0
field 27 endcode    = 0
field 28 startstack = 0

A runtime then fails to find stack address 0 in /proc/self/maps and reports:

stack not found in /proc/self/maps

In the traced run, that failure caused the process to raise SIGABRT:

rt_sigqueueinfo(tid=1, sig=6, si_code=-1)

Expected Behavior

/proc/self/stat field 28 should contain the initial user stack pointer, or at minimum an address inside the tracked [stack] VMA.

It should not be 0 while /proc/self/maps reports a valid [stack] range.

Actual Behavior

/proc/self/stat field 28 is always emitted as 0 by the synthetic stat formatter.

Relevant Code

In src/runtime/procemu.c, the /proc/self/stat formatter includes:

"18446744073709551615 0 0 0 0 0 0 "

Those fields correspond to:

rsslim startcode endcode startstack kstkesp kstkeip ...

So startstack is currently hard-coded to 0.

Suggested Fix

Record the initial guest user stack pointer during bootstrap/exec and emit it as field 28 in /proc/self/stat.

If elfuse does not yet store the exact initial SP, use a conservative address inside the tracked stack VMA until exact tracking is added.

The /proc/self/task/<tid>/stat formatter should also avoid reporting startstack as 0 if consumers may read task stat instead of process stat.