Closed Bug 1187826 Opened 6 years ago Closed 5 years ago
Gonk and Gecko cannot be built for 64bit (aarch64) devices
User Agent: Mozilla/5.0 (X11; CrOS armv7l 7077.95.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.90 Safari/537.36 Steps to reproduce: When building for a newer 64bit capable device, gonk makes bad assumptions about the compiler. https://github.com/mozilla-b2g/gonk-misc/blob/master/default-gecko-config#L13 is assuming that all ARM devices use the `arm-linux-androideabi` toolchain. Forcing this to `aarch64-linux-android` is a temp solution. The next issue is that https://github.com/mozilla-b2g/gonk-misc/blob/master/Android.mk#L395 is causing invalid options to be passed to the compiler (specifically `-mfpu=neon`). Forcing https://github.com/mozilla-b2g/gonk-misc/blob/master/default-gecko-config#L65 to `toolchain-default` seems to be a good temp solution. After that gonk is happy, but gecko fails early, with errors such as: `/gecko/toolkit/crashreporter/google-breakpad/src/common/android/include/sys/ucontext.h:166:4: error: #error "Unsupported Android CPU ABI!"` `../dist/include/nspr/prtime.h:48:17: error: conflicting declaration 'typedef PRInt64 PRTime' ../dist/include/nsrootidl.h:14:17: note: previous declaration as 'typedef int64_t PRTime'`
Yeah I don't think we do support ARM64 at all for now. But we are happy to take patches :)
Well, as Alex said, I doubt that we support ARM64 so far. Aarch64 uses different ABIs, so for example, we need private vendor binary blobs recompiled for Aarch64 because some of them are dynamically loaded so they need to be in the same Aarch as the loader. Another difference is that advanced SIMD is part of the Aarch64 standard, so there's no need to use options flags for the compiler to generate SIMD instructions (so yes, no -mfpu=whatever is needed). It'll be interesting to investigate that, because ARM64 is being supported by Android since 5.0, so we would need to support it as well sooner or later :)
I think the hardest bit of arm64 support has landed - spidermonkey JITs support it. That was bug 1088326. Everything else shouldn't be too bad, with the exception of xpconnect.
Depends on: 1088326
Building Gecko with arm64 support used to work, see bug 962534. If something has broken that in the meantime, it would be good to get it fixed.
Nothing to add.
(In reply to Nathan Froyd [:froydnj][:nfroyd] from comment #4) > Building Gecko with arm64 support used to work, see bug 962534. If > something has broken that in the meantime, it would be good to get it fixed. We'll just need to add support on the gonk side then.
So, should we start on this?
Yeah, all major vendors are moving to 64 bits so I think that we should as well.
By the way, on android, some modules still needs to be built by 32bit. OMX sw codec seems not work well on 64bit. https://android.googlesource.com/platform/frameworks/av/+/f87e30f%5E!/
64bit devices are actually multilib devices, they contain both 32bit and 64bit copies of everything. Actually there is more 32bit because several parts are forced to build 32bit only (eg Camera HAL). We can also do this with B2G. Building 64bit Gecko is a disaster that will not be solved soon, so we can accelerate use of 64bit devices by building Gecko as 32bit. However to use the 32bit libs we need to export the out/.../obj_2nd/lib directory to Gecko, which needs configure.in changes. The advantage? Bring up a device to a good state with a 32bit Gecko, then use that device to start fixing the 64bit build of Gecko. Test device: Wileyfox Swift. Mostly functional - audio, display, 3D gfx, CAMERA!!, sensors, wifi, GSM (partially, will need some quirks for data). The device does not have NFC, bluetooth does not yet activate.
The changes needed to configure.in for the multilib build. I need to know if these paths are used solely by building Firefox OS, if so this change is safe, we simply replace our hardcoded path with the path generated by Android.
(In reply to Adam Farden [:adfad666] from comment #10) > We can also do this with B2G. Building 64bit Gecko is a disaster that will > not be solved soon, so we can accelerate use of 64bit devices by building > Gecko as 32bit. Can you file bugs for these issues? Why is that so bad?
Those paths are just for gonk. The android port's paths are setup in a different file.
Comment on attachment 8699827 [details] Gonk patch I would prefer that as an explicit workaround behind something like "GECKO_GONK_32BITS_ON_AARCH64"
I've made building as the 2nd arch optional and clarified the new variables.
Attachment #8699827 - Attachment is obsolete: true
Bugs _are_ open, some of them for more than a year, like Bug 1069556 for example.
Comment on attachment 8700012 [details] [diff] [review] Gecko PR Seems reasonable. Don't know how I feel about the name of this variable, but that's not a big deal.
Attachment #8700012 - Flags: feedback?(mwu) → feedback+
I've move the 32bit patches to a more specific bug so we can get them merged. see Bug 1245088
Attachment #8700010 - Attachment is obsolete: true
Attachment #8700012 - Attachment is obsolete: true
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.