1471132 - Change how static xpcom components are linked/initialized

Status: RESOLVED FIXED

(Core :: XPCOM, enhancement)

Comment 1

[Mike Hommey [:glandium]]

Attachment: Bug 1471132 - Avoid ASAN padding between NSModules.

Review commit: https://reviewboard.mozilla.org/r/253010/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/253010/

Comment 2

[Mike Hommey [:glandium]]

Attachment: Bug 1471132 - Change how static xpcom components are linked.

Overall, this makes the whole setup less fragile, and make it work with
LTO in more situations.

Review commit: https://reviewboard.mozilla.org/r/253012/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/253012/

Comment 3

[Mike Hommey [:glandium]]

Attachment: Bug 1471132 - Change how static xpcom components are initialized.

The sStaticModules list is, practically speaking, a copy of the list
of components we already have in libxul, augmented at runtime with
a few other components for tests (for gtest and xpcshell). We don't
actually need to keep that copy in memory. We can instead just use the
pointers in libxul directly to register them to the component manager,
and use a separate list, only for those extra components when they need
to be registered.

Review commit: https://reviewboard.mozilla.org/r/253014/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/253014/

Comment 4

[Mike Hommey [:glandium]]

Attachment: Bug 1471132 - Make building a binary component a compile-time error.

Loading binary components is not supported since bug 1314955.

Review commit: https://reviewboard.mozilla.org/r/253016/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/253016/

Comment 5

[Mike Hommey [:glandium]]

Comment on attachment 8987742 [details]
Bug 1471132 - Change how static xpcom components are linked.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/253012/diff/1-2/

Comment 6

[Mike Hommey [:glandium]]

Comment on attachment 8987743 [details]
Bug 1471132 - Change how static xpcom components are initialized.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/253014/diff/1-2/

Comment 7

[Mike Hommey [:glandium]]

Comment on attachment 8987744 [details]
Bug 1471132 - Make building a binary component a compile-time error.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/253016/diff/1-2/

Comment 8

[Nathan Froyd [:froydnj]]

Comment on attachment 8987744 [details]
Bug 1471132 - Make building a binary component a compile-time error.

https://reviewboard.mozilla.org/r/253016/#review259668

Comment 9

[Nathan Froyd [:froydnj]]

Comment on attachment 8987743 [details]
Bug 1471132 - Change how static xpcom components are initialized.

https://reviewboard.mozilla.org/r/253014/#review259672

Comment 10

[Nathan Froyd [:froydnj]]

Comment on attachment 8987741 [details]
Bug 1471132 - Avoid ASAN padding between NSModules.

https://reviewboard.mozilla.org/r/253010/#review259676

Comment 11

[Nathan Froyd [:froydnj]]

Comment on attachment 8987742 [details]
Bug 1471132 - Change how static xpcom components are linked.

https://reviewboard.mozilla.org/r/253012/#review259690

::: toolkit/library/moz.build
(Diff revision 2)
> -SOURCES += [
> -    'StaticXULComponentsStart.cpp',
> -]
> -
> -# This, combined with the fact the file is first, makes the start pointer
> -# it contains first in Windows PGO builds.
> -SOURCES['StaticXULComponentsStart.cpp'].no_pgo = True
> -
> -# Don't let LTO reorder StaticXULComponentsStart.o.
> -for f in CONFIG['OS_CXXFLAGS']:
> -    if f.startswith('-flto'):
> -        SOURCES['StaticXULComponentsStart.cpp'].flags += ['-fno-lto']
> -        break
> -

So nice to get rid of this.

Comment 12

[Mike Hommey [:glandium]]

Comment on attachment 8987741 [details]
Bug 1471132 - Avoid ASAN padding between NSModules.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/253010/diff/1-2/

Comment 13

[Mike Hommey [:glandium]]

Comment on attachment 8987742 [details]
Bug 1471132 - Change how static xpcom components are linked.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/253012/diff/2-3/

Comment 14

[Mike Hommey [:glandium]]

Comment on attachment 8987743 [details]
Bug 1471132 - Change how static xpcom components are initialized.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/253014/diff/2-3/

Comment 15

[Mike Hommey [:glandium]]

Comment on attachment 8987744 [details]
Bug 1471132 - Make building a binary component a compile-time error.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/253016/diff/2-3/

Comment 16

[Mozilla Autoland]

We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again.

hg error in cmd: hg rebase -s 480ea315a847ffb63a8cb1e583669a61f1a7f3eb -d 9f4d1a4296ba: rebasing 469902:480ea315a847 "Bug 1471132 - Avoid ASAN padding between NSModules. r=froydnj"
rebasing 469903:de968c61dc4e "Bug 1471132 - Change how static xpcom components are linked. r=froydnj"
rebasing 469904:1a32c95312d8 "Bug 1471132 - Change how static xpcom components are initialized. r=froydnj"
rebasing 469905:cc224240c4f7 "Bug 1471132 - Make building a binary component a compile-time error. r=froydnj"
rebasing 469906:c6259994c6c0 "Bug 1447116 - Update builders to rust 1.28. r=froydnj"
merging taskcluster/ci/toolchain/windows.yml
warning: conflicts while merging taskcluster/ci/toolchain/windows.yml! (edit, then use 'hg resolve --mark')
unresolved conflicts (see hg resolve, then hg rebase --continue)

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dfd0afd7b60f
Avoid ASAN padding between NSModules. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/7839040f0d42
Change how static xpcom components are linked. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/32d574a02a2e
Change how static xpcom components are initialized. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/b7873993686f
Make building a binary component a compile-time error. r=froydnj

Comment 18

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/dfd0afd7b60f
https://hg.mozilla.org/mozilla-central/rev/7839040f0d42
https://hg.mozilla.org/mozilla-central/rev/32d574a02a2e
https://hg.mozilla.org/mozilla-central/rev/b7873993686f

Comment 19

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: Bug 1471132 - Handle 3-column nm/readelf output in check_binary r=glandium (esr60)

Comment 20

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Comment on attachment 9035860 [details] [diff] [review]
Bug 1471132 - Handle 3-column nm/readelf output in check_binary r=glandium (esr60)

This is one of series of patches I am requesting uplift to esr60. Please don't uplift any if the entire series won't go. The whole series will need to go in one push.

This try run (applied on tip-of-esr60 as of an hour ago; and beginning with 'Bug 1491901 - move MK*SHLIB to moz.configure') represents the patch series. It must be applied in that order: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0659d6e265f3b624ad6fbac0c9cd7ce246094596 (If this try run doesn't complete successfully, I will investigate and figure out why)

The uplift request form is the same for all of the patch series; see https://bugzilla.mozilla.org/show_bug.cgi?id=1491901#c10

Comment 21

[Julien Cristau [:jcristau]]

Comment on attachment 9035860 [details] [diff] [review]
Bug 1471132 - Handle 3-column nm/readelf output in check_binary r=glandium (esr60)

approved for 60.5esr

Comment 22

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-esr60/rev/6be34dffbc74