1595805 - Undefined symbols when linking macosx cross-compiled build with ASAN and fuzziness

Status: RESOLVED FIXED

(Infrastructure & Operations :: Infrastructure: Tools, defect)

Description

[Dzmitry Malyshau [:kvark]]

There is a strange linking issue with https://phabricator.services.mozilla.com/D49458 , described in detail in https://github.com/rust-lang/rust/issues/66285

Basically, linking libgkrust.a with optimization, ASAN, and fuzziness, from linux to macosx, may strip out some of the objects (like "spirv_cross.o"), which later fails to link into "XUL" with "Undefined symbols..." error.

Comment 1

[Dzmitry Malyshau [:kvark]]

Attachment: Disable LTO on macosx fuzzy builds

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8984a9fbc4e0
Disable LTO on macosx fuzzy builds r=froydnj

Comment 3

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/8984a9fbc4e0

Comment 4

[Dzmitry Malyshau [:kvark]]

Nathan, should we be keeping the bug open in order to eventually address this better than the workaround merged?

Comment 5

[Nathan Froyd [:froydnj]]

(In reply to Dzmitry Malyshau [:kvark] from comment #4)

Nathan, should we be keeping the bug open in order to eventually address this better than the workaround merged?

LTO is a performance optimization which I don't think fuzzing builds are going to worry too much about, so I'd be OK with either leaving open or closing, with a slightly preference for closing.

Comment 6

[Dzmitry Malyshau [:kvark]]

I'm seeing new link errors, which look very much related, now on other OSX targets and Windows MinGW:
https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=286028360&revision=79a071bf26b5a3da9904a7ebd8d5bae48f4b443c

Notice the previous try of the same jobs - https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=286028349&revision=9085fdb3dde4e841375002a20f21c0f5dbf9aff5
No spirv_cross stuff was changed in-between, the new commits just add wgpu functionality.

Nathan, would you have any suggestions on how to approach this? Would disabling LTO on all those targets be even an option?

Comment 7

[Nathan Froyd [:froydnj]]

(In reply to Dzmitry Malyshau [:kvark] from comment #6)

I'm seeing new link errors, which look very much related, now on other OSX targets and Windows MinGW:
https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=286028360&revision=79a071bf26b5a3da9904a7ebd8d5bae48f4b443c

Notice the previous try of the same jobs - https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=286028349&revision=9085fdb3dde4e841375002a20f21c0f5dbf9aff5
No spirv_cross stuff was changed in-between, the new commits just add wgpu functionality.

Nathan, would you have any suggestions on how to approach this? Would disabling LTO on all those targets be even an option?

I have no problem with turning off LTO on the MinGW builds (unless Tor is using LTO, ni? to tjr for that).

I'm less excited about turning off LTO on the Mac opt builds, but we could prooobably get away with that?

Unfortunately, LTO is required on the mac shippable instrumented build (and even if we turned it off there, we use LTO on the profile-use build, and I'd bet the same problem would show up there), so we have to fix that. It sounds like the Rust issue that you filed just stalled out? We might be able to get mw to help debug this if we had a kind of stripped-down testcase, which it sounds like https://github.com/rust-lang/rust/issues/66285#issuecomment-552543578 had?

Comment 8

[Tom Ritter [:tjr]]

(In reply to Nathan Froyd [:froydnj] from comment #7)

I have no problem with turning off LTO on the MinGW builds (unless Tor is using LTO, ni? to tjr for that).

I believe their build just uses our configuration settings when you set --enable-optimize and export MOZILLA_OFFICIAL=1

https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/firefox/mozconfig-windows-x86_64

So disabling LTO for MinGW would wind up disabling it for them I think...