Closed
Bug 560464
Opened 15 years ago
Closed 14 years ago
Trace Monkey doesn't build with "-mcpu=cortex-a9".
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: jbramley, Assigned: jbramley)
Details
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•15 years ago
|
||
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?
Assignee | ||
Comment 2•15 years ago
|
||
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.
Assignee | ||
Comment 3•15 years ago
|
||
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.
Assignee | ||
Comment 4•15 years ago
|
||
(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•14 years ago
|
||
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•14 years ago
|
||
Reported at bug #582593
Comment 7•14 years ago
|
||
I assume someone with appropriate permissions should resolve this bug like #582593 as invalid since it is due to a gcc bug?
Assignee | ||
Comment 8•14 years ago
|
||
Yep, looks like the same issue.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•