Closed Bug 1630189 Opened 5 years ago Closed 3 years ago

Windows 2012 x64 PGO build has a linking error where as other PGO build are green.

Categories

(Firefox Build System :: Toolchains, defect)

Product:
Firefox Build System
Component:
Toolchains
Platform:
x86_64
Windows 10
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: allstars.chh, Unassigned)

Details

See https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&revision=ad3f58c996e59bc5ca0a0e6aac61c8f6a7e51096&searchStr=Bpgo

The windows 2012 x64 shippable opt build has build error,
The error log is
[task 2020-04-10T14:54:07.595Z] 14:54:07 INFO - lld-link: error: undefined symbol: void (__cdecl *js::HelperThreadTaskCallback)(class mozilla::UniquePtr<struct js::RunnableTask, struct JS::DeletePolicy<struct js::RunnableTask>>)
[task 2020-04-10T14:54:07.595Z] 14:54:07 INFO - >>> referenced by /builds/worker/checkouts/gecko/js/xpconnect/src/XPCJSRuntime.cpp:3013
[task 2020-04-10T14:54:07.596Z] 14:54:07 INFO - >>> lto.tmp:(private: void __cdecl XPCJSRuntime::Initialize(struct JSContext *))
[task 2020-04-10T14:54:07.596Z] 14:54:07 INFO - /builds/worker/checkouts/gecko/config/rules.mk:608: recipe for target 'xul.dll' failed
[task 2020-04-10T14:54:07.596Z] 14:54:07 ERROR - make[4]: *** [xul.dll] Error 1

but the variable is defined in
https://hg.mozilla.org/integration/autoland/rev/ad3f58c996e59bc5ca0a0e6aac61c8f6a7e51096#l4.13

And other platforms PGO build are green, not sure why only windows x64 has this problem.

Hi :dmajor,
It looks like this is a bug in windows pgo build, can you give me some suggestions how to fix this?

Thanks

Flags: needinfo?(dmajor)

Interesting. I will need to run some builds locally which will take a little bit of time. How urgently is this blocking?

great, not urgent at the moment. :D

Interestingly, the error message says "referenced by XPCJSRuntime.cpp:3013", even though the only reference should be from jsapi.cpp. This suggests that SetHelperThreadTaskCallback got inlined into XPCJSRuntime::Initialize, and somehow ThinLTO didn't do the right updates to carry the imports from one file to the other.

If you need to get unblocked, could you try adding MOZ_NEVER_INLINE to SetHelperThreadTaskCallback?

Before reporting to this at LLVM I would like to try it out on a trunk compiler, maybe it's already fixed in 11.0.

Flags: needinfo?(dmajor)

I just tried with clang 10.0.0 and it looks like it's fixed there.

Yes, use MOZ_NEVER_INLINE fixes this problem, thanks :D.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: General → Toolchains

Looks like this is an old, now-fixed in clang, problem. Closing.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.