In the 32-bit parisc runtime, the first four non floating-point
arguments are passed in registers (%r26, %r25, %r24 and %r23).
The remaining arguments are passed on the stack. There are four
reserved slots on the stack that the callee can use to save the
first four argument registers if the callee desires.
The StubN functions are special in that arguments are not explicitly
declared. %r26 is used for the "self" pointer. The call to SharedStub(n)
loads n into %r26 and clobbers the "self" pointer in %r26. The hppa
SharedStub implementation expects to find the "self" pointer on the
stack in the slot reserved for StubN. However, gcc doesn't copy any
arguments to the stack as no arguments are declared for StubN. Even
if it did, there's no guarantee that we could force gcc to save the
argument on the stack as that's more expensive than copying to a
free register. Thus, we need to copy %r26 to the stack slot manually.
The invoke_copy_to_stack() function passes incorrect "stack_args" and
"end" arguments to the alloc_word() utility function, for parameter types
T_I8..T_I64, T_U8..T_U64, T_BOOL, T_CHAR and T_WCHAR.
Namely, the "end" input parameter of invoke_copy_to_stack(), which is
currently incorrectly passed as "end" to alloc_word(), points to the very
end of the entire exchange area between _NS_InvokeByIndex() and
invoke_copy_to_stack(). However, alloc_word()'s "end" parameter should
point to the end of the "ireg" (integer registers) sub-area of the
exchange area. That is, "ireg_end" should be passed to alloc_word() as
"end".
Because invoke_copy_to_stack()'s "end" input parameter is strictly greater
than "ireg_end", alloc_word() will happily trample over the "freg"
(floating point registers) area, on the above-mentioned type branches,
given a large enough "paramCount".
Similarly, as second argument, "stack_args" should be passed to
alloc_word(), pointing to the next available stack slot, for spilled-over
arguments. Passing "stk", which initially points to the base of the entire
exchange area (and hence the base of the "ireg" area) makes no sense.
The two other alloc_word() calls in the function are correct. So
centralize all calls to alloc_word() to a single location -- thereby
ending up with a sole call site per alloc_XXX() function --, and compute
only the last argument, "word", conditionally.
This fixes an obscure SIGSEGV in AARCH64 Firefox. Triggering the bug
requires a target function with seven integer-like parameters (not
counting the implicit "this" -- aka "that" -- parameter), followed by at
least one parameter of the above buggy types. nsIOService::NewChannel2()
is such a target function, for example.
DONTBUILD because NPTOB
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
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.
xptcstubs_arm mostly works on iOS but Apple's assembler is ridiculous so
the inline assembly for the SharedStub and the stub methods needs judicious
preprocessor use.
--HG--
extra : commitid : ChAcktTzVX0
extra : rebase_source : 11fbaa4940fd9aaeba51e2477d4c8b1a7851791e
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
As explained in bug 1111355, having avx enabled appears to change the
alignment behavior of alloca (apparently adding an extra 16 bytes) of
padding/alignment (and using 32-byte alignment instead of 16-byte). The
suggestion of using __bultin_alloca_with_align in bug 1111355 didn't fix
the problem, so this seems to be the best available workaround, given
that this code, which should perhaps better be written in assembly, is
written in C++.
Interestingly, this is NOT fixed by #pragma GCC target ("arch=x86-64").
(I determined the (undocumented) name for the default -march value on
x86_64 from the gcc source code (gcc/config/i386/i386.c, function
ix86_option_override_internal, code that sets opts->x_ix86_arch_string .)
I confirmed that this sets the same macros based on the empty diff
between the output of 'gcc -E -dM -x c++ /dev/null' and 'gcc -E -dM -x
c++ -march=x86-64 /dev/null', which was not an empty diff for other
-march values (e.g., k8).)
I confirmed that the push_options and pop_options actually work by
putting the push/pop pair around a different (earlier) function, and
testing that this did not fix the bug (with the pop_options before
NS_InvokeByIndex).
See the gcc documentation at:
https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Function-Specific-Option-Pragmas.htmlhttps://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Function-Attributes.htmlhttps://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/i386-and-x86-64-Options.html
--HG--
extra : transplant_source : %DA%7CJ4H%DE%80%15%84%0D%116%85Q%9A%F9%2C%D1v%16
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
This fixes the download panel issue, and brings us revs 727721e5d8ac,
844b142d8111 and 236989b3a807 as a bonus. Remove the unmaintained
OpenBSD/amd64 specific versions.
Sylvestre Ledru
Benjamin Smedberg
Wes Kocher
John David Anglin
John Paul Adrian Glaubitz
Andrew McCreight
Nathan Froyd
Trevor Saunders
Eric Rahm
Laszlo Ersek
Tom Tromey
Chris Peterson
Christian Holler
Paul Bignier
Jan Beich
Ted Mielczarek
Nicholas Nethercote
David Major
Andrew McCreight
Heiher
Mike Hommey
Ginn Chen
Ehsan Akhgari
James Cowgill
L. David Baron
Masatoshi Kimura
Trevor Saunders
Landry Breuil
Thomas Klausner
Jacob Bramley