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] |
On 11/29/2017 09:51 PM, Rich Felker wrote:
I'm not sure I follow, but from the standpoint of virtual address space and what is an acceptable cost in wasted address space, any ILP32-on-64 ABIs should be considered the same as 32-bit archs. As such, I think GCC really needs to do the stack probe every 4k, not 64k, and the default (and certainly minimum-supported) guard size should be kept at 4k, not 64k or anything larger.
Yes, and I expect that we will keep using 4 KiB probing on i386 (and s390/s390x). That's what Jeff gave me for testing. I do hope the final upstream version isn't going to be different in this regard.
But in the end, this is up to the machine maintainers (for gcc and glibc).
We can throw new code at this problem and solve it for 64-bit. For 32-bit, we simply do not have a universally applicable solution. My understanding was that everywhere except on ARM, GCC was compatible with the pioneering glibc/Linux work in this area (the guard page we added to thread stacks, and the guard page added by the kernel). If this isn't the case, then I'm really disappointed in the disregard of existing practice on the GCC side.Hm? What are you thinking of that GCC might have gotten wrong?
Use 64 KiB probe intervals (almost) everywhere as an optimization. I assumed the original RFC patch was motivated by that.
I knew that ARM would be broken because that's what the gcc ARM maintainers want. I assumed that it was restricted to that, but now I'm worried that it's not.
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |