Did very old versions of the NDK use 64kb alignment?

[Andreas Falkenhahn]

Hi,

I'm currently migrating my app to support the new 16kb alignment requirement so I recompiled the native bits of my app using the latest NDK 29 which according to the docs will always build shared objects that use a 16kb alignment. This is what readelf reports about the shared object built using NDK 29:

===========================================================================================

Elf file type is DYN (Shared object file)
Entry point 0x0
There are 9 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000001f8 0x00000000000001f8 R 0x8
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000380940 0x0000000000380940 R E 0x4000
LOAD 0x0000000000380940 0x0000000000384940 0x0000000000384940
0x00000000000214b8 0x00000000000216c0 RW 0x4000
LOAD 0x00000000003a1df8 0x00000000003a9df8 0x00000000003a9df8
0x000000000004462f 0x000000000005a57c RW 0x4000
DYNAMIC 0x000000000039f808 0x00000000003a3808 0x00000000003a3808
0x00000000000001f0 0x00000000000001f0 RW 0x8
GNU_RELRO 0x0000000000380940 0x0000000000384940 0x0000000000384940
0x00000000000214b8 0x00000000000216c0 R 0x1
GNU_EH_FRAME 0x00000000000c9e04 0x00000000000c9e04 0x00000000000c9e04
0x000000000000ba6c 0x000000000000ba6c R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x0
NOTE 0x0000000000000238 0x0000000000000238 0x0000000000000238
0x00000000000000bc 0x00000000000000bc R 0x4

Section to Segment mapping:
Segment Sections...
00
01 .note.android.ident .note.gnu.build-id .dynsym .gnu.version .gnu.version_r .gnu.hash .hash .dynstr .rela.dyn .rela.plt .rodata .eh_frame_hdr .eh_frame .text .plt
02 .data.rel.ro .fini_array .dynamic .got .got.plt .relro_padding
03 .data .bss
04 .dynamic
05 .data.rel.ro .fini_array .dynamic .got .got.plt .relro_padding
06 .eh_frame_hdr
07
08 .note.android.ident .note.gnu.build-id

===========================================================================================

This makes perfect sense because we can clearly see that ALIGN is set to 0x4000 here, i.e. 16kb. Out of curiosity I had a look at what readelf said about the very same project but this time compiled with the very old NDK r14b which I was previously using to build the native parts of my app. Surprisingly, it said this:

===========================================================================================

Elf file type is DYN (Shared object file)
Entry point 0x514c0
There are 7 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000037a5d8 0x000000000037a5d8 R E 0x10000
LOAD 0x000000000037b270 0x000000000038b270 0x000000000038b270
0x0000000000076f40 0x000000000008d0d0 RW 0x10000
DYNAMIC 0x000000000039a7d8 0x00000000003aa7d8 0x00000000003aa7d8
0x0000000000000240 0x0000000000000240 RW 0x8
NOTE 0x00000000000001c8 0x00000000000001c8 0x00000000000001c8
0x0000000000000024 0x0000000000000024 R 0x4
GNU_EH_FRAME 0x000000000033a744 0x000000000033a744 0x000000000033a744
0x000000000000c19c 0x000000000000c19c R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x000000000037b270 0x000000000038b270 0x000000000038b270
0x0000000000022d90 0x0000000000022d90 R 0x1

Section to Segment mapping:
Segment Sections...
00 .note.gnu.build-id .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .plt .text .rodata .eh_frame_hdr .eh_frame
01 .init_array .fini_array .data.rel.ro .dynamic .got .data .bss
02 .dynamic
03 .note.gnu.build-id
04 .eh_frame_hdr
05
06 .init_array .fini_array .data.rel.ro .dynamic .got

===========================================================================================

As you can see ALIGN is not set to 0x1000 here as I'd have expected because all Google docs that I read said that previously the NDK built shared objects that used an alignment of 4kb. Instead it is set to 0x10000, i.e. 64kb which is 4 times the current page size requirement. This is confusing me. Could somebody shed some light on what's going on here? I'd expect all my old shared objects compiled using NDK r14b to use an alignment of 0x1000 but instead they all seem to be using 0x10000?!

So does that mean I don't even have to recompile them for the new 16kb requirement because strictly speaking a shared object which is 64kb aligned is also 16kb aligned just like shared objects that are 16kb aligned are also 4kb aligned and work on devices that have use a 4kb page size...

Does anybody have an idea what's going on here? Thanks!

--
Best regards,
Andreas Falkenhahn mailto:and...@falkenhahn.com

[enh]

TL;DR: "yes".

i don't have a citation, but, "yeah, that matches my memory of gnu
gold's behavior".
https://github.com/bminor/binutils-gdb/commit/7572ca8989ead4c3425a1500bc241eaaeffa2c89
is sort-of a citation (where in 2014 gnu ld was making arm32 match
arm64's _existing_ behavior), showing i'm not just making stuff up.

> --
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/android-ndk/30299cf2-87a4-4132-aed8-7ca6d0f17e01%40falkenhahn.com.

[Andreas Falkenhahn]

Thanks, and Play Store won't complain when trying to upload apps that use 64kb aligned native components or do they enforce strict 16kb alignment?

[enh]

over-alignment should be fine. +Steven Moreland to confirm...

To view this discussion visit https://groups.google.com/d/msgid/android-ndk/10d3bb93-e1a9-414a-8a1d-da8c01d186b8%40falkenhahn.com.

[Steven Moreland]

Yes, 64 KB alignment is also 16 KB aligned, it's okay!