Commit graph

5 commits

Author SHA1 Message Date
Matt A. Tobin
12097d40a2 Fix build errors with newer glibc versions 2019-10-18 09:04:57 +08:00
wolfbeast
769e5dad1e Remove AIX 1st party code OS checks, part 1
Issue #186
2019-04-04 20:26:39 +08:00
wolfbeast
78d61fd2b1 Issue #187: Remove solaris conditional code. 2019-04-04 20:26:26 +08:00
wolfbeast
e9342c1ad5 Issue #578: Applications cannot start without /proc (chroot).
UXP uses the current stack frame address and the stack size
as a sort of heuristic for various things in the JavaScript
engine.  The js::GetNativeStackBaseImpl() function is used to
get the base stack address (i.e. the address from which the stack
grows, so this can be either the first or last memory address of
the stack memory space depending on the CPU architecture).

On Linux, this function is implemented using the pthreads APIs.
For non-main threads, the queried thread info is stored in
memory.  The main thread does not have this information on hand,
so it gets the stack memory range via the /proc/self/maps file
(see glibc's pthread_get_attr_np.c).

Fortunately (per discussions with the firefox devs in #jsapi)
the base address only needs to be approximate.  In reality,
environment variables, args, and other things are stored in
stack space between the end/beginning of the mapped stack
memory and the 'top' of the stack space used by stack frames.

When using glibc, we can get the top of this usable stack from
__libc_stack_end, which is a void* set by glibc during program
initialization, avoiding the need to access /proc.
Non-main threads still get their stack-base through the usual
pthreads APIs.
Other libc implementations like musl will fall back to the
standard UNIX-like implementation which calls pthread's
pthread_attr_getstack() also from the main thread, which
may imply /proc access and not work in restricted
environments.
2019-02-16 00:06:45 +08:00
Roy Tam
dcd9973243 import FIREFOX_52_6_0esr_RELEASE from mozilla-esr52 hg repo 2018-01-19 03:59:58 +08:00