zend stack: prepare zend_call_stack_get implementation for OpenBSD. #11578
Conversation
Zend/zend_call_stack.c
Outdated
| // TODO may need more leeway for the main thread | ||
| stack->max_size = ss.ss_size; |
There was a problem hiding this comment.
Are we able to get the actual ss_sp for the main thread? Does the stack reside in its own memory mapping, and can we find the address of this mapping?
Otherwise, do we have a way to estimate the right size for the leeway? Does it depend on the arguments and environment size?
There was a problem hiding this comment.
Are we able to get the actual
ss_spfor the main thread?
Yes, if pthread_stackseg_np succeeds you always get it.
Does the stack reside in its own memory mapping, and can we find the address of this mapping?
Otherwise, do we have a way to estimate the right size for the leeway? Does it depend on the arguments and environment size?
Looking at openbsd source, it seems the proper calculation is done already since years now, back in the days you needed to do the alignment yourself. What you re looking at is the main thread case and it depends on the arguments and environment indeed, done in the kernel side of things here.
There was a problem hiding this comment.
Is it possible that the alignment is not enough to take sgap and sizeof(arginfo) into account? VM_PSSTRINGS is vm->vm_minsaddr - sizeof(arginfo) - sgap, and sgap appears to be in [0..pagesize], so I understand that VM_PSSTRINGS can be more than 1 page way from vm_minsaddr. In that case, we would need to add 1 page of leeway.
|
This looks good to me. In case I'm correct about VM_PSSTRINGS, could you remove one page from max_size? Otherwise could you remove the TODO comment? This PR supports detecting stack boundaries on OpenBSD when linking with pthread; do you plan to add support for non-pthread in a separate PR? |
devnexen
force-pushed
the
zend_call_stack_openbsd
branch
from
f41843e to
4f4eab9
Compare
Yes that s part of the plan indeed. Cheers. |
No description provided.