On 07/30/2012 08:48 PM, Jiří Zárevúcky wrote: > Jakub has already told me on IRC that current stacks do not grow and > there is no protection against overflow.
Yes, for the record, there is an open ticket for this: #382. > The question is, how difficult would it be to implement growing > stacks? Is it even possible with the way memory management is > currently implemented? It wouldn't be probably too difficult to allocate stacks so that there is a guard page at its both ends. One would basically need to tell the kernel to unmap the guard pages and not allocate their virtual addresses to someone else. Perhaps a specialized address space area type would do. Growing the stacks can be potentially somewhat harder. It would be necessary to implement a mechanism that would move the as area base to a lower address, if available. The impulse to grow the as area downwards could be inferred by the kernel from some flag in the address space area or could be a result of the uspace reacting to some end-of-stack event, as it it implemented e.g. in Windows. For the latter, the use of kernel notifications comes to mind. > There is also one possibility that would be relatively simple to > implement, and that is segmented stacks. Segmented stacks are > discontiguous and the segments are allocated on demand. There are two > drawbacks. A minor one is that there is an overhead of few > instructions per function call. A major one is that it needs linker > support, and currently only gold linker supports it. However, HelenOS > can't be build with gold linker (I tried and it can't digest our > linker script). Perhaps someone could fix that? It would certainly be interesting to explore this idea a little further. Btw, can gold target all platforms needed by HelenOS? And if yes, is this split stack feature supported on all of them? IIRC, it was only implemented (perhaps on the gcc side) for x86. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
