The particular syntax for this warning is an MSVC extension, which
causes clang-cl to fallback to MSVC when compiling files that use this
macro. Trying to use nsPrintfCString or equivalent here runs into
issues of unused variables in non-debug builds. I think it's reasonable
to raise an warning without a specific location; folks can grovel about
in a debugger if they want to figure out what's going on.
fix_stack_using_bpsyms.py locates a .sym file based on file name only, not uuid or full path,
which causes a failure if a duplicate leaf file name is introduced. This patch introduces a
small utility program on mac and linux to extract a breakpad guid from a shared library or
executable to identify the correct symbol file when this ambiguity occurs. A subsequent commit
implements this for windows.
--HG--
extra : commitid : 2O7REfHuDus
This is OK from a security perspective, since this decision only affects
whether the channel will be intercepted with the secure URI in the child
process. If the intercepting service worker decides to fall back to an
actual network request, we send the request to the parent process with
the original pre-upgrade URI, and the parent process will still be in
charge of whether a network visible HTTP request should be upgraded.
This is needed to ensure that the ServiceWorkerManager uses the
correct URI for non-subresource requests. Note that we're relying
on the property that non-secure non-subresource requests can never
be intercepted, so we don't need to check the request type explicitly.
glandium suggests doing this to fix l10n builds. This is a shot in the
dark. It should either work or completely break things.
--HG--
extra : rebase_source : cd4923a7532ae74b21548792ff0c7ef885952aeb
- dom.vr.enabled is now "true" by default for non-release builds.
- dom.vr.add-test-devices is now "0" by default, so that content may detect
VR devices accurately.
This is glandium's suggested patch. Committing under his name reviewed
by me.
--HG--
extra : commitid : 5abfwXR51iA
extra : rebase_source : d7d3658687e5b825e2095682786653cc42bf201e
extra : amend_source : fde873074c7e5d29f0fd9b5452ed5d1bed2f279d
On win32, NS_InvokeByIndex is implemented with inline assembly. This
inline assembly assumes that it is wrapped by the compiler with the
standard x86 prologue and epilogue:
push ebp
mov ebp, esp
[inline assembly that manipulates the stack pointer]
pop ebp
ret
In particular, the last instruction of the inline assembly is:
mov esp, ebp
which cancels out the effects of the stack manipulation performed by all
the inline assembly that proceeds the instruction.
When compiling with clang-cl, however, the above assumption does not
hold, as clang-cl inserts a more complex prologue and epilogue,
something like:
push ebp
mov ebp, esp
sub esp, frame_size
[save registers into stack frame]
[inline assembly that manipulates the stack pointer]
[restore registers from stack frame]
add esp, frame_size
mov esp, ebp
pop ebp
ret
Combining this more extensive prologue and epilogue with the assumptions
of the inline assembly leads to interesting crashes when
NS_InvokeByIndex is called: the inline assembly effectively deallocates
the stack allocated by the inline assembly *and* the stack frame
allocated by the compiler itself. The compiler-generated code then
attemptes to deallocate the stack frame, leading to the crash, as the
code now returns to an unspecified address.
To avoid these sorts of problems in clang-cl and make the code more
robust generally, let's move the NS_InvokeByIndex implementation to a
separate assembly file. We can then write exactly what we need to have
happen, safe from any manipulations of the compiler.
Since we don't compile much (any?) code in Gecko with MASM, we need to
add the /SAFESEH flag to the assembler invocation so that the object
file with be appropriately marked as not containing exception handlers;
the linker (which is invoked with the /SAFESEH flag itself) will then
consent to link it into libxul.
This is OK from a security perspective, since this decision only affects
whether the channel will be intercepted with the secure URI in the child
process. If the intercepting service worker decides to fall back to an
actual network request, we send the request to the parent process with
the original pre-upgrade URI, and the parent process will still be in
charge of whether a network visible HTTP request should be upgraded.
This is needed to ensure that the ServiceWorkerManager uses the
correct URI for non-subresource requests. Note that we're relying
on the property that non-secure non-subresource requests can never
be intercepted, so we don't need to check the request type explicitly.
Nathan Froyd
Chris Manchester
Ehsan Akhgari
Josh Matthews
Jordan Lund
Henrik Skupin
Daniel Holbert
Ben Kelly
Benoit Girard
Gregory Szorc
Tooru Fujisawa
Armen Zambrano Gasparnian
Kearwood (Kip) Gilbert
Andrea Marchesini
Mike Hommey
Wes Kocher
Mike Conley
Gabor Krizsanits