This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Quick access to stack bounds


On 12/05/2009 05:50 PM, Richard Henderson wrote:
#define AT_STACK_TOP 26

	Filled in by the kernel with the top of the stack of the main
	thread.  The bottom of the stack is of course __libc_stack_end.

This is needed for other reasons as well. Only problem is that as long as there still is a PROT_GROWS{UP,DOWN} implementation in the kernel the answer is not definitive. I said for a long time that these options should be removed since they cannot possibly be used in a safe way. So I suggest your patch does it as well.



tcbhead_t->__private_tm[3]

Redefined to be the bottom of the stack of any thread.

tcbhead_t->__private_tm[4]

Redefined to be the top of the stack + SPLIT_STACK_AVAILABLE.

Why the addend? We already have this information (except for the initial thread and if pthread_attr_setstackaddr is used). We keep the stack address and the size around.


Changing this to two addresses is possible but must be justified.

The problem is that in theory this information can be used now. It would of course be much better to use what is available. I realize that this might not be the best solution but I want to see real reasons.

it's also not ideal to use offsets into the TCB which are that deep. It means that a lot of care must be applied but this can be automated.


	If the kernel doesn't provide AT_STACK_TOP, we *could* use
	getrlimit(RLIMIT_STACK) to fill in the value instead.

Not really. Often the value is unlimited. What then? And see the comment on PROT_GROWS*.



 I'm
	undecided whether it's better to simply do this once in libc
	or force all users of this interface to check for NULL and
	fill it in from getrlimit themselves.

*Iff* the TCB is used then all of glibc will be changed to use the values, replacing the existing TCB fields. Then we'd initialize the variables extremely early in the startup code.


--
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]