560464 - Trace Monkey doesn't build with "-mcpu=cortex-a9".

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Jacob Bramley [:jbramley]]

I can't build a working Trace Monkey on Karmic using GCC 4.4.1 and "-mcpu=cortex-a9". I see the same problem in JaegerMonkey, but Trace Monkey is probably a simpler debug target.

----

To reproduce:

export FLAGS_A9="-mcpu=cortex-a9 -mfpu=vfp -mfloat-abi=softfp"
export FLAGS_A8="-mcpu=cortex-a8 -mfpu=vfp -mfloat-abi=softfp"   # For comparison.

# A known-bad revision is '9540de6aaed6', but I also tried several others with no success.

CFLAGS=$FLAGS_A9 CXXFLAGS=$FLAGS_A9 CPPFLAGS=$FLAGS_A9 /moz/tm/js/src/configure --disable-debug --enable-optimize

make
# The 'make' command will run for a while, then fall over with the following error:

/home/ubuntu/moz/tm.release/config/nsinstall -R -m 755 libmozjs.so dist/sdk/lib ./dist/bin/js imacro_asm.js /moz/tm/js/src/imacros.jsasm > imacros.c.tmp
Segmentation fault
make[1]: *** [libs] Error 139
make[1]: Leaving directory `/home/ubuntu/moz/tm.release'
make: *** [default] Error 2

----

Observation of the disassembly and the nature of the crash suggests a compiler bug, but now I'm not sure. I'm very suspicious that we might be violating strict-aliasing rules somewhere in a way that doesn't affect the optimizations made for Cortex-A8, but does affect those made for Cortex-A9.

Comment 1

[David Mandelin [:dmandelin]]

That build step is after the JS shell was successfully built. It is using the JS shell to run a script that compiles a file for "imacros" (interpreter bytecode macros), which is used by the tracer. But it's running without the tracer. So that means you have a shell, but the interpreter crashes running that program.

Strict-aliasing issues sound quite possible. Does it work if you build with --disable-optimize?

Comment 2

[Jacob Bramley [:jbramley]]

Hmm. Actually I hit an assertion with a debug build of _Jaeger_ Monkey using 4.4.1 (Karmic) and FLAGS_A8, but I don't see the same problem with 4.3.3 (Jaunty) and exactly the same compiler switches.

I do see some warnings about strict aliasing, so I will investigate those.

Our compiler team advised me to try a newer compiler, but I will try to identify the problem as this could be important. Strict aliasing bugs, for instance, can disappear only to reappear later.

Comment 3

[Jacob Bramley [:jbramley]]

The following generates a warning about strict aliasing on GCC 4.4.1 (ARM, Karmic): http://hg.mozilla.org/users/danderson_mozilla.com/jaegermonkey/file/60f8b06c0c4b/js/src/jsobjinlines.h#l410

The code was removed from the Trace Monkey tree, and I don't get any other warnings, but strict-aliasing rules are hard for the compiler to detect so I'm not ruling it out.

Comment 4

[Jacob Bramley [:jbramley]]

(In reply to comment #1)
> Strict-aliasing issues sound quite possible. Does it work if you build with
> --disable-optimize?

Yes, for both JM and TM, though JM with "-m" (but not "-jm") seg faults on a simple 'for' loop. I don't see any problem on 4.3.3 in any configuration.

(Without --disable-optimize, I get the fault even with both JITs disabled.)

It is not going to be easy to track down the source of this problem. I see none of these issues with 4.3.3, and I see slightly different symptoms with different build options. (Sometimes I get assertion failures, but sometimes I just see seg faults). The faulting code doesn't look obviously broken, so I suspect something higher-level (such as strict aliasing). Tracking this down is not a trivial task, however!

----

I will try a newer compiler and see if the problems goes away.

Comment 5

[Loïc Minier]

Hey folks,

While rebuilding Ubuntu's firefox and xulrunner-1.9.2 packages with a new GCC 4.4.x based toolchain (looking similar to CodeSourcery's), we hit an issue which looks really similar:
https://bugs.launchpad.net/gcc-linaro/+bug/604874

It might be that small differences in alignment trigger this kind of bug; Ulrich Weigand debugged this and came to the conclusion some static array isn't sufficiently aligned.

Would you advice us on which way you'd like to solve this?  We plan to add gcc alignment macros for now as a workaround, but perhaps you can recommend some mozilla-ish alignment macros which would be more portable, or perhaps we should get rid of the requirement to align on 8-bytes on ARM?

Comment 6

[Loïc Minier]

Reported at bug #582593

Comment 7

[Adrian Bunk]

I assume someone with appropriate permissions should resolve this bug like #582593 as invalid since it is due to a gcc bug?

Comment 8

[Jacob Bramley [:jbramley]]

Yep, looks like the same issue.