Quick access to stack bounds

[Ulrich Drepper]

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 ❖