Closed Bug 701708 Opened 10 years ago Closed 10 years ago

Rebuild NDK armv6 STLport as arm instead of thumb on build machines


(Infrastructure & Operations Graveyard :: CIDuty, task, P3)



(Not tracked)



(Reporter: ted, Unassigned)


(Keywords: mobile, Whiteboard: [mobile][armv6])


(1 file)

If we target armv6, currently we have to build --with-thumb=no because a bunch of our code doesn't build in an armv6+thumb configuration. Unfortunately, this causes us to crash on startup, because STLport is built with thumb, and the mismatch is somehow fatal. Rebuilding STLport as arm-only makes this issue go away.

We either need to:
a) Rebuild the STLport in the NDK we're using to be arm-only
b) Fix our code to compile with armv6+thumb
c) Figure out why this mismatch crashes and work around it in some other way

a) is the only one I've tested successfully so far.
Is there any confusion here between thumb and thumb2?  I was under the impression that our thumb build option was sometimes labeled as "thumb" and sometimes as "thumb2", but really represented thumb2 throughout.  Thumb and thumb2 are different instruction sets.
The --with-thumb argument just controls passing "-mthumb" to the compiler. glandium says that GCC will select thumb or thumb2 as appropriate depending on the -march. I think our codebase assumes thumb2 in a few places, which is why we break when building with armv6+thumb.
I think thumb code in ARMv6 is really slow. Probably 'a' is the best solution. Or maybe we should try all the solutions and see which one is better in terms of performance.
Keywords: mobile
OS: Windows 7 → Android
Hardware: x86_64 → ARM
If someone wants to do the investigation, feel free. I've done a) and know it works, so I'm going to proceed with that solution since it's a lot less work than the others.

I'm going to move this to Release Engineering to get a fixed STLport.

The steps we need to do on the build machines (that produce our android builds) are:
1) Apply a patch to the NDK build scripts for STLport (to be provided shortly)
2) Rebuild STLport in the NDK (this can be done on just one machine and copied to the others)
3) Push the new bits out to all build slaves
Component: Build Config → Release Engineering
Product: Core →
QA Contact: build-config → release
Summary: Sort out STLport arm vs. thumb issues for armv6 builds → Rebuild NDK armv6 STLport as arm instead of thumb on build machines
Version: Trunk → other
You'll need to apply this patch to the NDK, then run build/tools/ That will produce new binaries in the right places.
Priority: -- → P3
Whiteboard: [mobile]
Priority: P3 → --
Whiteboard: [mobile] → [mobile][triagefollowup]
Component: Release Engineering → Release Engineering: Platform Support
Priority: -- → P3
QA Contact: release → coop
Whiteboard: [mobile][triagefollowup] → [mobile][armv6]
I think we're going to skip this and go with the solution Mike came up with in bug 734050 instead.
Closed: 10 years ago
Resolution: --- → WONTFIX
No longer blocks: 697205
Product: → Release Engineering
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.