joleson needs a new arm64 simulator variant in autospider.sh.
As per bug 1208118 comment 1, I think it's time to cut our losses and do this in buildbot. There's no point in getting this to work in taskcluster if we can't move all the builds over yet anyway.
jolesen: I think the arm-sim build wants to be built with a 32-bit gcc. Does this one? It doesn't look like it from your variants/ file, but I just wanted to check.
Created attachment 8668187 [details] [diff] [review] Define arm64-sim variant Hmm... seems like there ought to be more required than this, but I'm not seeing anything. And I'm not sure who to give this review to anymore, it's been so long. bhearsum: note that I am doing this in buildbot, not taskcluster, because the taskcluster builds don't work on all platforms that SM wants yet. So it seems pointless to hold this up on that migration when it can't be a full migration yet anyway.
Attachment #8668187 - Flags: review?(bhearsum)
Assignee: jolesen → sphink
Status: NEW → ASSIGNED
The simulators must be built with a pointer size identical to the simulated architecture. So arm-sim requires 32-bit and arm64-sim requires 64-bit.
(In reply to Steve Fink [:sfink, :s:] from comment #1) > As per bug 1208118 comment 1, I think it's time to cut our losses and do > this in buildbot. There's no point in getting this to work in taskcluster if > we can't move all the builds over yet anyway. Even if OS X and Windows can't be done right this minute, why can't new Linux stuff go in Taskcluster?
(In reply to Ben Hearsum (:bhearsum) from comment #5) > (In reply to Steve Fink [:sfink, :s:] from comment #1) > > As per bug 1208118 comment 1, I think it's time to cut our losses and do > > this in buildbot. There's no point in getting this to work in taskcluster if > > we can't move all the builds over yet anyway. > > Even if OS X and Windows can't be done right this minute, why can't new > Linux stuff go in Taskcluster? Because there's still work to be done there before we can replace the bb jobs. It is mainly that afaik they are not set up, nor is there any way to set them up, to only run when something touches js/src. We could eliminate that restriction, but it would bump up the load of spidermonkey jobs by a fair amount. I intend to look into implementing that scheduling, as well as a handful of other features (which are all or almost all needed by new jobs, not existing ones). But I don't have the bandwidth atm. Also, looking at the existing jobs, it looked like there might be some things missing, though I'm not entirely sure. They don't seem to get their compiler via tooltool -- which maybe just means they're doing it in a better way now? (eg as part of a docker image or something.) They don't set $AUTOMATION, so they're following a slightly different codepath from existing jobs. Assuming these are even problems, they're all fixable (and I have an in-progress patch that does so.) But they're further obstacles to turning them on right now.
Comment on attachment 8668187 [details] [diff] [review] Define arm64-sim variant When you have time, I think #taskcluster will probably be quite happy to help you out with the remaining issues. At a certain point I suspect we're going to stop accepting new jobs in Buildbot, so your hand may be forced if you don't have by then :)
Attachment #8668187 - Flags: review?(bhearsum) → review+
The arm64 build is broken again this morning. We need CI coverage rather urgently. Bug 1210456 - ARM64: Build fails with missing js::jit::AtomicOperations::loadSafeWhenRacy functions If TaskCluster does not have the features needed by SpiderMonkey today, I would agree with sfink that we should enable arm64-sim in buildbot first and then start working on TaskCluster support.
See Also: → bug 1210456
Oops, this bug can be closed. When I migrated the other linux-based spidermonkey jobs to TC, I did the arm64 build too.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.