On 07/26/18 17:07, Rich Felker wrote:
> There's a PT_GNU_STACK ELF program header that's normally only used to
> request non-executable stack, but it can also specify a stack size the
> program wants. This is used (and was historically required) for
> FDPIC/NOMMU targets to tell the kernel how much stack to reserve for
> the main thread, and is conventionally left at 0/default for normal
> ELF, but ld is capable of writing a custom size with
> -Wl,-z,stacksize=X.
> 
> So, we could automatically increase __default_stacksize according to
> max(current,dso.pt_gnu_stacksize.p_memsz) for the main program and
> each loaded dso. This would make it possible to work around programs
> that need large stacks but don't explicitly request them without
> patching, by instead just adding the appropriate LDFLAGS.
> 
> Are there any significant cons to doing this? Would it help
> distros/integrators?
> 
> Rich


Short answer: YES!


Long answer:

One of the stickiest issues we've (Adélie) had with the default thread
stack size on musl is not really patching programs (that's easy, and
most upstreams actually do appreciate the conformance help).

It's Mozilla products.

There is no single place where a thread is spawned in Gecko / XPCOM /
MozJS.  It's a mess to try and fix it, so we haven't.

And that means that pages that use very deeply nested JavaScript... some
examples, off the top of my head:

- AT&T's landing pages
- Blue Cross of Oklahoma
- Forbes (magazine)
- Google Maps
- Namecheap's domain renewal page

... crash the browser because they exceeded the thread stack size.

Being able to simply add a linker flag that would "magically" fix this
for Firefox would be a huge win for us.


Best,
--arw

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org