Re: Detailed Stack Information Patch [2/3]

Mikael Pettersson
2009-04-03T08:55:46Z

Stefani Seibold writes:
> Am Freitag, den 03.04.2009, 09:32 +0200 schrieb Mikael Pettersson:
> > Stefani Seibold writes:
> > > I think a user space daemon will be the a good way if the /proc/*/maps
> > > or /proc/*/stack will provide the following information:
> > >
> > > - start address of the stack
> > > - current address of the stack pointer
> > > - highest used address in the stack
> >
> > You're assuming
> > 1. a thread has exactly one stack
> > 2. the stack is a single unbroken area
> > 3. the kernel knows the location of this area
> >
> > None of these assumptions are necessarily valid, esp. in
> > the presence of virtualizers, managed runtimes, or mixed
> > interpreted/JIT language implementations.
>
> We are talking about the kernel view. And from this point a thread has
> only one stack and it is a single mapped continuous area. There are only
> one exception and that is the sigaltstack().

So you're proposing to have the kernel export data which,
while accurate from the kernel's limited view, may be
arbitrarily inaccurate for the user-space process in question?

Also I'm not sure you even need a kernel extension for the
optimistic case of a single simple stack. ptrace to get stack
pointer then scan /proc/$tid/maps to identify the corresponding
mapping should give the same information, no?