1494907 - Disable static analysis with 32-bit windows for TaskCluster

Status: RESOLVED WONTFIX

(Firefox Build System :: Task Configuration, task)

Description

[John Dai[:jdai]]

In bug 1475415, we hit an "LLVM ERROR: out of memory" in rustc when building windows 2012 opt static-analysis-win32-st-an/opt (s)[1]. Here are some discussion about disabling static analysis with 32-bit windows:

> <jdai> Maybe there are some reasons we keep our clang / llvm 32 bits. If so, I have to find another way to narrow down memory consumption in the build time. 
> <froydnj> we can do a 64-bit clang sort of reasonably, but the sticking point is the clang-plugin see some of the sad stories in bug 1429549
> <froydnj> I guess we could just stop doing static analysis on 32-bit windows? w00, aarch64 windows xul.dll just linked the next moment of truth: packaging
> <•ted> froydnj: that's...probably fine actually? (re: no static analysis on win32)


[1] https://treeherder.mozilla.org/logviewer.html#?job_id=201454570&repo=try&lineNumber=25778

Comment 1

[Mike Hommey [:glandium]]

I think we can actually do static analysis with the 64-bits clang-cl now. (bug 1469091 essentially addressed bug 1429549). The problem is that we're stuck with clang 5-ish for static analysis and can't use the same 64-bits clang-cl we use for normal builds.

Comment 2

[John Dai[:jdai]]

(In reply to Mike Hommey [:glandium] from comment #1)
> I think we can actually do static analysis with the 64-bits clang-cl now.
> (bug 1469091 essentially addressed bug 1429549). The problem is that we're
> stuck with clang 5-ish for static analysis and can't use the same 64-bits
> clang-cl we use for normal builds.

I tried setting win64-bits clang-cl for win32-st-an/opt in taskcluster/ci/static-analysis/kind.yml, but it fails with build error: https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=203362825&revision=5fb55b2f6df48b350c7e976ddd08f08e9d5eca4c

Comment 3

[(not currently active) Ted Mielczarek]

Yeah, that would presumably be bug 1427808. Unless someone actually wants to tackle fixing that I think disabling these builds is probably fine.

Comment 4

[Mike Hommey [:glandium]]

(In reply to Ted Mielczarek [:ted] [:ted.mielczarek] from comment #3)
> Yeah, that would presumably be bug 1427808. Unless someone actually wants to
> tackle fixing that I think disabling these builds is probably fine.

It can't be the same as bug 1427808. That one comes from upgrading the clang version, which is not the case here. The same version of clang builds the plugin just fine on 64-bits static analysis builds.

Comment 5

[Mike Hommey [:glandium]]

I've gone a little further down the road with:
https://hg.mozilla.org/try/rev/ba711cdbfd5113ed54ad5606fa7a6c35fc40c572

which now fails with:
z:/build/build/src/clang/bin/lld-link.exe: error: libcpmt.lib(syserror.obj): machine type x86 conflicts with x64

which is a similar problem to the one in bug 1479800: LIB pointing to x86 directories. To make this work, we need to kill LIB and pass those paths through LDFLAGS/HOST_LDFLAGS with -LIBPATH.

Also, I found bug 1414287, which is about what we're trying here.

Comment 6

[Mike Hommey [:glandium]]

This is also a similar problem to that which was addressed in bug 1401647 with WIN64_LINK/WIN64_LIB, which retrospectively seems not to have been the best thing to do.

Comment 7

[Mike Hommey [:glandium]]

OTOH, we also don't pass HOST_LDFLAGS down to rust...

Comment 8

[(Away)]

When bug 1490948 enabled Cranelift, it made an exception for Win32 static analysis due to the added code triggering OOMs: https://hg.mozilla.org/integration/mozilla-inbound/rev/4d9500ca5761

I guess libxul has kept growing to the point that we trigger OOMs with or without Cranelift now. If the Win32 tasks get disabled, or moved to a 64-bit host, the Cranelift workaround could be removed.

Comment 9

[Mike Hommey [:glandium]]

Wontfixing this in favor of bug 1414287