Closed Bug 1449066 Opened 3 years ago Closed 3 years ago

Switch hazard builds to GCC 6


(Firefox Build System :: General, enhancement)

3 Branch
Not set


(firefox61 fixed)

Tracking Status
firefox61 --- fixed


(Reporter: glandium, Assigned: sfink)




(2 files)

No description provided.
> ERROR: xgill compiled with 6.4.0 but running inside 4.9.4!

is /builds/worker/workspace/sixgill/usr/libexec/sixgill/scripts/wrap_gcc/gcc not using the gcc from the toolchain package?
Flags: needinfo?(sphink)
Gah, the plugin is actually still built with 4.9 after bug 1444543
Depends on: 1444543
Flags: needinfo?(sphink)
Steve, can you check why this is failing with hazards detected?
  TEST-UNEXPECTED-FAIL 160 rooting hazards detected
Flags: needinfo?(sphink)
  TEST-UNEXPECTED-FAIL 162 rooting hazards detected
  TEST-UNEXPECTED-FAIL 47 heap write hazards detected out of 0 allowed
Attachment #8962615 - Flags: review?(core-build-config-reviews) → review?(nfroyd)
Comment on attachment 8962615 [details]
Bug 1449066 - Switch hazard builds to GCC 6.

Attachment #8962615 - Flags: review?(nfroyd) → review+
That's odd. When I (just now, as a result of this bug) looked at what was going on, it looked to me like sixgill was being built with gcc 6 but tested with gcc 4. When I switched it to pull in gcc 6 from the toolchain (as you did in this patch), I got weird assembler errors:

/tmp//ccUK6FnU.s: Assembler messages:
/tmp//ccUK6FnU.s:45: Error: expecting string instruction after `rep'

From googling, it seems those are associated with older binutils, but I got the same thing after upgrading to 2.27.

Oh well, if it's working for you, I won't complain. Looking at the hazards now.
All of the hazards I looked at are from an invalid call chain -- it thinks tryNewTenuredThing<allowGC = 0>() can call GCRuntime::gc(), which it can't because that's the whole point of AllowGC. But somehow with gcc 6 it thinks it can. Rather strange, given that GCC itself is generating the call; this isn't some weirdness of the analysis code. I will import the changes here and do a try push with --upload-xdbs to see what's going on.
Ugh. Optimization doesn't seem to be happening in the same way.

The code says

    if (MOZ_UNLIKELY(!t && allowGC && otherstuff)) { ... }

(allowGC is the constant zero in this case, so the whole thing should be discarded.) GCC 6 is translating that, in this state of optimization at least, to

    t = refillFreeListFromAnyThread(cx, kind);
    if (t) {
        __temp_4 = 0;
        __temp_3 = MOZ_UNLIKELY(__temp_4);
        if (__temp_3) {
    } else {
        ...exact same thing...
    checkIncrementalZoneState(cx, t);
    return t;

For comparison, gcc 4.9 produced

    t = refillFreeListFromAnyThread(cx, kind, thingSize);
    checkIncrementalZoneState(cx, t);
    return t;

Ugh. I'll work around this with an annotation. I hope the optimizer *does* handle this at some stage. Hm... disassembly seems to say that it does. This whole function is inlined into js::Allocate, and in the case here it does a tail call to refillFreeListFromAnyThread (which is fair because checkIncrementalZoneState is empty if non-DEBUG.) So this appears to be an artifact of DEBUG + different optimizations kicking in before the plugin sees the code.
The annotation appears to mostly work, though I think there's still a single remaining hazard that is unrelated. I'm going to have to run off to bed before I can check the latest results, though: (that may need a retry on the decision task if it times out again, as it has been doing recently.)

Remaining hazard is in
Function 'js::jit::AbortReasonOr<js::jit::MCall*> js::jit::IonBuilder::makeCallHelper(const mozilla::Maybe<mozilla::Vector<JSFunction*, 6ul, js::jit::JitAllocPolicy> >&, js::jit::CallInfo&)'

has unrooted 'target' of type 'JSFunction*' live across GC call 
'js::jit::AbortReasonOr<bool> js::jit::IonBuilder::testShouldDOMCall(js::TypeSet*, JSFunction*, JSJitInfo::OpType)' at js/src/jit/IonBuilder.cpp:5557

where that GC call invokes an "instanceChecker" function pointer. I'll look into it tomorrow. I thought this stuff generally runs within a GC suppression?
Requesting review on the annotations so far, though they're pretty simple.
Attachment #8963464 - Flags: review?(jcoppeard)
Assignee: mh+mozilla → sphink
Attachment #8963464 - Flags: review?(jcoppeard) → review+
Oh, bleh. This looks like a real issue; the internal CFG must have added something that sixgill doesn't know how to handle. The hazard is because of a missing call edge from IonBuilder::setPropTryCommonSetter to IonBuilder::makeCallHelper from the line

    MOZ_TRY_VAR(call, makeCallHelper(targets, callInfo));

sixgill's translation of that line is

  Assign(119,120, mozTryVarTempResult_:1 := error*)

'error' is not a variable; it's a sixgill fallback for stuff it doesn't understand but so far hasn't been enough of a problem to matter. MOZ_TRY_VAR is

#define MOZ_TRY_VAR(target, expr) \
  do { \
    auto mozTryVarTempResult_ = (expr); \
    if (mozTryVarTempResult_.isErr()) { \
      return ::mozilla::Err( \
          mozTryVarTempResult_.unwrapErr()); \
    } \
    (target) = mozTryVarTempResult_.unwrap(); \
  } while (0)

so really it's the translation of

    auto mozTryVarTempResult_ = makeCallHelper(targets, callInfo);

For the record, makeCallHelper returns js::jit::AbortReasonOr<js::jit::MCall*> which is mozilla::Result<MCall*, AbortReason>  which ends up boiling down to roughly struct { uint8 rawData[8]; tag uint8; }. (Which is a little sad, because there are only 6 AbortReasons and they would fit in the 3 low-order bits of an aligned pointer.) I'll have to step through sixgill's processing of this line.
Flags: needinfo?(sphink)
Blocks: 1449094
No longer blocks: 1449094
Depends on: 1450379
Pushed by
Switch hazard builds to GCC 6, r=froydnj
Annotate more func<AllowGC::NoGC> as not being able to GC, r=jonco
Er, oops. I kinda pushed my local import of the reviewboard patch along with my patches. (And it is incorrectly listed as being written by me, because the reviewboard link I used only gave me the diff, and I didn't bother to look further because I only wanted it for testing.)

On the bright side, it landed and it's green. :-)
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Version: Version 3 → 3 Branch
You need to log in before you can comment on or make changes to this bug.