The original changeset that is being backed out had comment:
Bug 1023941 - Part 5: Loader hook to redirect the missing import.
The changes made in bug 1023941 were to work around the fact that with VS2013, msvcr120.dll imports kernel32!GetLogicalProcessorInformation, which is not available on Windows XP SP2.
In VS2015, the GetLogicalProcessorInformation requirement has moved into concrt140.dll (concurrency runtime), which we don't use.
So, now that our build infra is building with VS2015, we can remove the hooking and static runtime linking required to get the VS2013 fix to work.
In addition we need to do that to be able us to link the Chromium sandbox code into firefox.exe and get it to build and run with both VS2015 and VS2013.
MozReview-Commit-ID: 1tlXaYJ8dHH
- HAVE_RANDOM is not checked at all.
- HAVE_STRERROR is not checked in code built using the defines from the main
configure.
- HAVE_LCHOWN is only checked in nsinstall.c, which means the test is also wrong
since it's checking for the target instead of the host. Also, lchown is only
used of the -o and -g options of nsinstall, which, as far as I know, we don't
use (and if we were, that would fail with nsinstall.py, which explicitly rejects
them).
- HAVE_FCHMOD is only checked in nsinstall.c, so same as above about the
correctness of the check. If it's not available, nsinstall.c falls back to
chmod, which is fine enough for our use.
- HAVE_SNPRINTF is not checked.
- HAVE_MEMMOVE is checked in parser/expat/lib/xmlparse.c, but it's also
unconditionally defined in expat_config.h which is included from that file.
- HAVE_SETBUF is checked in a couple files, but setbuf is C89 and C99, I think
it's safe to assume all compilers we support are C89 and C99. Interestingly,
windows does have it, but since we skip this check on windows, we don't use it.
- HAVE_ISATTY, same as HAVE_SETBUF, except it's POSIX instead of C89/C99.
- HAVE_FLOCKFILE is not checked at all.
- HAVE_STRTOK_R is not checked.
- HAVE_FT_SELECT_SIZE is not checked.
- HAVE_DLADDR is not checked under js/src.
- HAVE_GETPAGESIZE is not checked under js/src (it is in libffi, but ffi uses
its own configure)
- HAVE_LSTAT64, HAVE_STAT64, HAVE_STATVFS, HAVE_STATVFS64, HAVE_TRUNCATE64 are
not checked under js/src.
- HAVE_SBRK is not checked under js/src. Moreover,
js/src/assembler/wtf/Platform.h defines it depending on the platform.
- HAVE_SNPRINTF is not checked under js/src.
- HAVE_HYPOT is not checked under js/src.
- HAVE__UNWIND_BACKTRACE is not checked under js/src.
With this patch, I've confirmed that we instantiate the SafeJSContext much later
in startup, during nsAppStartupNotifier::Observe (which ends up invoking an
XPCWrappedJS). As such, this should solve a number of our startup ordering woes.
The JS engine fires this callback when the request count drops to zero, and we
use it determine when we should hibernate the watchdog thread. But since the
request count never drops to zero for nested event loops, the watchdog never
runs in those cases. And since our xpcshell harness runs tests in a nested event
loop, this means we can't test watchdog hibernation from xpcshell. And we don't
want to test it in mochitests, because the non-determinism of timer CCs and GCs
are likely to be problematic.
Really, we should consider finding a way to integrate nested event loops into
the activity callback mechanism, and should probably get a bug on file. But such
a task is out of scope for this bug, so we just add a way to fake it.
XPCShell currently overrides all the JSContexts whose creation it observes with
its own custom error reporter. This reporter does all sorts of funny things which
we try to clean up for the most part. But there are a few very intricate
considerations at play.
First, the old xpcshell error reporter does some mumbo jumbo with the
XPCCallContext stack to try to guess whether some other code might catch the
exception. This is total garbage on a number of fronts, particularly because
the XPCCallContext stack has no concept of saved frame chains, nested event
loops, sandbox boundaries, origin boundaries, or any of the myriad of
complicating factors that determine whether or not an exception will propagate.
So we get rid of it. But this causes some crazy debugger tests to fail, because
they rely on an exception from uriloader/exthandler/nsHandlerService.js getting
squelched, and can't handle anybody reporting errors to the console service at
the particular moment of contortionism when the exception is raised. So we need
to introduce an explicit mechanism to disable the error reporter here to keep
things running.
Second, we have to be very careful about tracking the return status of the
xpcshell binary. The old code would simply flag an error code if the error
handler was invoked, and we can mostly continue to do that. But there are some
complications. See the comments.
Finally, we don't anything analogous in XPCShellEnvironment, because I have
patches in bug 889714 to remove its state-dependence on the error reporter.
I'll switch it to SystemErrorReporter in that bug.
XPCShell currently overrides all the JSContexts whose creation it observes with
its own custom error reporter. This reporter does all sorts of funny things which
we try to clean up for the most part. But there are a few very intricate
considerations at play.
First, the old xpcshell error reporter does some mumbo jumbo with the
XPCCallContext stack to try to guess whether some other code might catch the
exception. This is total garbage on a number of fronts, particularly because
the XPCCallContext stack has no concept of saved frame chains, nested event
loops, sandbox boundaries, origin boundaries, or any of the myriad of
complicating factors that determine whether or not an exception will propagate.
So we get rid of it. But this causes some crazy debugger tests to fail, because
they rely on an exception from uriloader/exthandler/nsHandlerService.js getting
squelched, and can't handle anybody reporting errors to the console service at
the particular moment of contortionism when the exception is raised. So we need
to introduce an explicit mechanism to disable the error reporter here to keep
things running.
Second, we have to be very careful about tracking the return status of the
xpcshell binary. The old code would simply flag an error code if the error
handler was invoked, and we can mostly continue to do that. But there are some
complications. See the comments.
Finally, we don't anything analogous in XPCShellEnvironment, because I have
patches in bug 889714 to remove its state-dependence on the error reporter.
I'll switch it to SystemErrorReporter in that bug.
