On Tue, Apr 12, 2022, 5:59 PM Paul Gofman <pgofman@codeweavers.com> wrote:

I don’t think this complication worth it. What we would like to save is address space on 32 bit, but we can’t (before running 32 on 64 of course where this stack will be on 64 only). We apparently need to reserve address space for stack at once, so it has the space to grow, and then growing would only mean saving committed pages.

Maybe allocate extra stack only for function calls that might need it? Something like this: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntddk-keexpandkernelstackandcallout

That can technically be made to work, but to do it we'd need:

- maintain some pool of larger thread kernel stacks;

- make a secondary switch to it in wine_unix_call or whenever we think we need a larger stack (as apparently it is not known in wine_syscall_dispatcher);

- hunt the functions requiring larger stack one by one.

All this together (and especially the last point) sounds like essentially a no go for me. Mind also that long term when 32 on 64 is on by default the syscall stack will exist on 64 only.