This commit contains a few things:
* Misc build fixup to sync with upstream--adding a few new moz.build files,
source files
* The final bits of unhooking Breakpad from the profiler:
** Revert to only building toolkit/crashreporter if MOZ_CRASHREPORTER.
** Stop building bits of Breakpad that we only needed for the profiler.
** Remove a few bits of profiler code that were used to interface with Breakpad.
** Remove toolkit/crashreporter/breakpad-logging, which was only used to
suppress Breakpad logging for the in-process stackwalker.
* Upstream removed their Android-compat sys/ucontext.h because the Android NDK
added it, but the bionic we're using for Gonk builds is too old, so add a
copy of the previous version of those files to
toolkit/crashreporter/gonk-include to keep Gonk building.
* Consolidate moz.build files under toolkit/crashreporter/google-breakpad/client/linux
--HG--
rename : toolkit/crashreporter/google-breakpad/src/client/linux/handler/Makefile.in => toolkit/crashreporter/google-breakpad/src/client/linux/Makefile.in
extra : commitid : HeAH4kH17B1
extra : rebase_source : c9942aaca1d4e9555ecd44a23d7020a8a7ba1d77
extra : source : 31c98f5e107b9271be88e7c8543c4dbb4a2b6526
This commit contains a few things:
* Misc build fixup to sync with upstream--adding a few new moz.build files,
source files
* The final bits of unhooking Breakpad from the profiler:
** Revert to only building toolkit/crashreporter if MOZ_CRASHREPORTER.
** Stop building bits of Breakpad that we only needed for the profiler.
** Remove a few bits of profiler code that were used to interface with Breakpad.
** Remove toolkit/crashreporter/breakpad-logging, which was only used to
suppress Breakpad logging for the in-process stackwalker.
* Upstream removed their Android-compat sys/ucontext.h because the Android NDK
added it, but the bionic we're using for Gonk builds is too old, so add a
copy of the previous version of those files to
toolkit/crashreporter/gonk-include to keep Gonk building.
* Consolidate moz.build files under toolkit/crashreporter/google-breakpad/client/linux
--HG--
rename : toolkit/crashreporter/google-breakpad/src/client/linux/handler/Makefile.in => toolkit/crashreporter/google-breakpad/src/client/linux/Makefile.in
extra : commitid : GR2H5y5DM7E
extra : rebase_source : 212b8f04703555658e1df026de2211ea20ac390b
This avoids large amounts of heap churn while watching YouTube videos on Mac
and Linux.
--HG--
extra : rebase_source : 8606947287574826c455c25336c1a42d77ce6dcc
This commit makes CycleCollectedJSRuntime install a nursery collection callback
which traces nursery collections with a new `mozilla::TimelineMarker` subclass.
They're trivial and very hot. This reduces binary size in a 64-bit Linux opt build by 20 KiB and avoiding the calls can only help performance.
--HG--
extra : rebase_source : 774e6ffff9c787fa5444f939d1236d994ac8cf5b
Since we no longer support binary extensions, revving an interface's IID
is not necessary for binary compatibility. However, we currently skip
relinking XPT files if a change to an interface doesn't update its IID.
This patch fixes that requirement by comparing full interfaces against
each other, so that updating an XPIDL interface without rvving its IID
works well with incremental builds.
This paves the way to remove the requirement on revving interface IIDs
when making a change to an XPIDL interface.
Nothing in mozilla-central uses the NS_APP_BOOKMARKS_50_FILE/BMarks key except
tests. It's also not been very useful since the switch to places in ... Firefox
3? so even if addons use it, it's not doing them much good.
BookmarkHTMLUtils.defaultPath returns the same thing anyways for those that
really do insist on getting the equivalent thing (but I'd argue
BookmarkHTMLUtils.defaultPath, as well as the browser.bookmarks.file pref could
just go away as well).
Seamonkey does use NS_APP_BOOKMARKS_50_FILE/BMarks, but they really only need
the #define, which they can add in their source.
Nothing apart the code that was just removed uses those keys, so remove them.
Actually, there is a use in Seamonkey, but considering they're shipping with
omnijar, the code expecting the directory has not been working as designed for
a while, so they can fixup and remove that use as well.
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.
A bunch of threads have their wait time set to PR_INTERVAL_NO_TIMEOUT and so
we divide this by 4 and set waitTime to that. This causes us to wait a very
long but not PR_INTERVAL_NO_TIMEOUT amount of time and so we still update
mIntervalNow and think that we've been hung for a long time when comparing
to the mInterval in the current thread which is set to the previous value of
mIntervalNow.
The JS engine does not export symbols outside of XUL, so having these
defined inside mozglue apparently causes linking errors on some
platforms with the patches in bug 1120016.
This patch moves enough methods outside of mozglue that the patch in
that other bug will still link on all platforms, without moving so
much out that there are other linking errors.
--HG--
rename : xpcom/glue/nsCycleCollectionParticipant.cpp => xpcom/base/nsCycleCollectorTraceJSHelpers.cpp
Ted Mielczarek
Chris Pearce
Bill McCloskey
Wes Kocher
Carsten "Tomcat" Book
ffxbld
Nicholas Nethercote
Xidorn Quan
Kyle Huey
Landry Breuil
Phil Ringnalda
Ryan VanderMeulen
Sylvestre Ledru
Tom Tromey
Eugen Sawin
Vladan Djeric
Aaron Klotz
David Rajchenbach-Teller
Bogdan Postelnicu
Nick Fitzgerald
Sebastian Hengst
Jeff Muizelaar
Ehsan Akhgari
Eric Rahm
Randell Jesup
Mats Palmgren
Jan de Mooij
Jan Beich
Terrence Cole
Wilmer Paulino
Mike Hommey
Christoph Kerschbaumer
Michael Layzell
Chris Manchester
Shu-yu Guo
Gabriele Svelto
Felix Janda
Nathan Froyd
Mike Conley
Olli Pettay
Makoto Kato
Jeff Walden
Chris Peterson
Geoff Brown
Kit Cambridge
Andrew McCreight
Birunthan Mohanathas
Andrea Marchesini
Daniel Holbert