-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Fill correct stack info in pthread_getattr_np stub #23887
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fill correct stack info in pthread_getattr_np stub #23887
Conversation
See use case here: https://github.com/python/cpython/pull/130398/files#diff-c22186367cbe20233e843261998dc027ae5f1f8c0d2e778abfa454ae74cc59deR365-R380 I guess for stack protection, this only enables introspecting whether we run out of the spill stack. I'm not sure whether to expect running out of spill stack or running out of true stack to be more common. But at least this unbreaks the code.
7c2c401
to
db7b108
Compare
… Emscripten Emscripten reports having `pthread_get_stackaddr_np` but it does nothing. I opened an upstream PR to actually fill in the stack information: emscripten-core/emscripten#23887 Until we can update to an Emscripten version that includes this fix, we can work around it by using `#define`s to replace `pthread_get_stackaddr_np` with the modified version.
… info in pthread_self_stub
The closure tests are now failing for me locally with:
|
I experimented with using static struct initializer instead but it looks like it actually caused and overall regression: #23904 |
… Emscripten Emscripten reports having `pthread_get_stackaddr_np` but it does nothing. I opened an upstream PR to actually fill in the stack information: emscripten-core/emscripten#23887 Until we can update to an Emscripten version that includes this fix, we can work around it by using `#define`s to replace `pthread_get_stackaddr_np` with the modified version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! LGTM
I guess this is still a few bytes bigger than before because we added |
@@ -1 +1 @@ | |||
129166 | |||
129206 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a 40 byte increase is more than I would expect from this change.. I was hoping for more like 6 bytes (2 bytes each for the 3 extra store instructions).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well we also added pthread_getattr_np.c
which looks like:
int pthread_getattr_np(pthread_t t, pthread_attr_t *a)
{
*a = (pthread_attr_t){0};
a->_a_detach = t->detach_state>=DT_DETACHED;
a->_a_guardsize = t->guard_size;
a->_a_stackaddr = (uintptr_t)t->stack;
a->_a_stacksize = t->stack_size;
return 0;
}
Presumably the other 34 bytes come from that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But that file should not linking into any of those tests. It should only be linked into the (rare) programs that use it.
See use case here:
https://github.com/python/cpython/pull/130398/files#diff-c22186367cbe20233e843261998dc027ae5f1f8c0d2e778abfa454ae74cc59deR365-R380
I guess for stack protection, this only enables introspecting whether we run out of the spill stack. I'm not sure whether to expect running out of spill stack or running out of true stack to be more common. But at least this unbreaks the code.