This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Quick access to stack bounds
On 12/09/2009 09:12 AM, Richard Henderson wrote:
The PROT_GROWS_DOWN implementation extends the vma? I had thought the
reserved address space was fixed and the flag was merely a hint for how
to allocate pages within that vma. That does add a wrinkle...
The problem with the PROT_GROWS* code is that it doesn't reserve the
VMA. I cannot, because it can grow indefinitely, if necessary. It just
extends the region when needed and based on heuristics (I *think* they
handle the case where the jump is large enough to skip a page).
Anyway, as I said this code cannot be used at all. The kernel can
allocate other VMA blocking the extension making the execution
unpredictable at best. In worse cases it'll result in silent
overwriting. If you propose a kernel change get rid of PROT_GROWS* at
the same time.
I'd like to support the more efficient form, but it's true that it
wouldn't be the end of the world to always use the lea form that's
already used for large frame sizes.
I really don't like adding unrelated and unused details like this offset
in the ABI.
The problem is that in theory this information can be used now. It would
of course be much better to use what is available.
It can? Where is this stored?
The stackblock and stackblock_size fields in struct pthread are
available. See also pthread_getattr_np().
As I said, these fields are deep down in the TCB but in theory they can
be used. The issue is the first threads stack.
What are your plans for the initial thread having an unlimited stack?
What is the stack size or stack base address?
--
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â