1187826 - Gonk and Gecko cannot be built for 64bit (aarch64) devices

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: GonkIntegration, defect)

Description

[Adam Farden [:adfad666]]

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'`

Comment 1

[Alexandre LISSY :gerard-majax]

Yeah I don't think we do support ARM64 at all for now. But we are happy to take patches :)

Comment 2

[Juan Gomez [:_AtilA_] (CET/CEST)]

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 :)

Comment 3

[Michael Wu [:mwu]]

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.

Comment 4

[Nathan Froyd [:froydnj]]

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.

Comment 5

[Mike Hommey [:glandium]]

Nothing to add.

Comment 6

[Michael Wu [:mwu]]

(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.

Comment 7

[Alexandre LISSY :gerard-majax]

So, should we start on this?

Comment 8

[Juan Gomez [:_AtilA_] (CET/CEST)]

Yeah, all major vendors are moving to 64 bits so I think that we should as well.

Comment 9

[Sotaro Ikeda [:sotaro]]

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!/

Comment 10

[Adam Farden [:adfad666]]

Attachment: Gonk patch

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.

Comment 11

[Adam Farden [:adfad666]]

Attachment: Gecko patch

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.

Comment 12

[[:fabrice] Fabrice Desré]

(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?

Comment 13

[Michael Wu [:mwu]]

Those paths are just for gonk. The android port's paths are setup in a different file.

Comment 14

[Alexandre LISSY :gerard-majax]

Comment on attachment 8699827 [details]
Gonk patch

I would prefer that as an explicit workaround behind something like "GECKO_GONK_32BITS_ON_AARCH64"

Comment 15

[Adam Farden [:adfad666]]

Attachment: Gonk Patch

I've made building as the 2nd arch optional and clarified the new variables.

Comment 16

[Adam Farden [:adfad666]]

Attachment: Gecko PR

Comment 17

[Adam Farden [:adfad666]]

Bugs _are_ open, some of them for more than a year, like Bug 1069556 for example.

Comment 18

[Michael Wu [:mwu]]

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.

Comment 19

[Adam Farden [:adfad666]]

I've move the 32bit patches to a more specific bug so we can get them merged. see Bug 1245088