All binaries and libraries are mapped rwx on both text and data

[Mike Hommey]

$ readelf -l system/lib/libc.so | grep LOAD
  LOAD 0x000000 0x00000000 0x00000000 0x4c6a4 0x57a54 RWE 0x8000

There's only one PT_LOAD sections in all binaries in both daily builds and local builds using the linaro toolchain.
Using the android toolchain from prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/ doesn't show this behaviour.

Using a simple test case, it appears ld in the linaro toolchain doesn't like the linker script used by the android build system.

----8<-----
int foo = 42;
int bar() { return 42; }
----8<-----

$ prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-gcc -nostdlib -Wl,-T,build/core/armelf.xsc -shared -o test.so test.c
$ readelf -l test.so|grep LOAD
  LOAD 0x000000 0x00000000 0x00000000 0x00298 0x00298 R E 0x1000
  LOAD 0x001000 0x00001000 0x00001000 0x0003c 0x0003c RW 0x1000

$ android-toolchain-eabi/bin/arm-eabi-gcc -nostdlib -Wl,-T,build/core/armelf.xsc -shared -o test.so test.c
$ readelf -l test.so|grep LOAD
  LOAD 0x000000 0x00000000 0x00000000 0x01068 0x01068 RWE 0x8000

However, using the default link script, there's no such problem:
$ android-toolchain-eabi/bin/arm-eabi-gcc -nostdlib -shared -o test.so test.c
$ readelf -l test.so|grep LOAD
  LOAD 0x000000 0x00000000 0x00000000 0x00234 0x00234 R E 0x8000
  LOAD 0x000234 0x00008234 0x00008234 0x00068 0x00068 RW 0x8000

[Mike Hommey (mh-glandium)]

Using this patch, I'm getting the expected result on binaries and libraries.
These lines were taken from the default linker script.

[Mike Hommey (mh-glandium)]

The build however fails:
out/host/linux-x86/bin/soslim --strip --shady --quiet out/target/product/pandaboard/symbols/system/lib/libmock_ril.so --outfile out/target/product/pandaboard/obj/lib/libmock_ril.so
external/elfcopy/elfcopy.c(2995): Section .ARM.exidx partially overlaps segment 2 in file.

$ readelf -l out/target/product/pandaboard/obj/SHARED_LIBRARIES/libmock_ril_intermediates/LINKED/libmock_ril.so

Elf file type is DYN (Shared object file)
Entry point 0xa44e0
There are 5 program headers, starting at offset 52

Program Headers:
  Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
  EXIDX 0x2424a4 0x002424a4 0x002424a4 0x0a158 0x0a158 R 0x4
  LOAD 0x000000 0x00000000 0x00000000 0x24c5fc 0x24c5fc R E 0x8000
  LOAD 0x24c5fc 0x002545fc 0x002545fc 0x0aea0 0x1a414 RW 0x8000
  DYNAMIC 0x2534d8 0x0025b4d8 0x0025b4d8 0x00110 0x00110 RW 0x4
  GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4

 Section to Segment mapping:
  Segment Sections...
   00 .ARM.exidx
   01 .hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text .rodata .ARM.extab .ARM.exidx
   02 .init_array .fini_array .data.rel.ro .dynamic .got .data .bss
   03 .dynamic
   04

Technically, elfcopy shouldn't error out :-/

[Mike Hommey (mh-glandium)]

Note: in practice the first hunk of the patch in each file is not necessary.

It looks like soslim is wrong and fails on the files you get with the new linker scripts :(

[Mike Hommey (mh-glandium)]

This works better, without modifying the linker script, and without modifying soslim. The main difference between the prebuilt toolchain and the linaro toolchain, that breaks things, is the max page size, which is 0x1000 on the prebuilt toolchain and 0x8000 on the linaro toolchain. Forcing it to 0x1000 (4096) everywhere make things more uniform.

[Michael Hope (michaelh1)]

Note that there is a mainline binutils vs Android binutils difference. Linaro don't produce a binutils.

The maximum page size is set in binutils/bfd/elf32-arm.c at 0x8000, and its been that way since June 1999 (!).

The binutils-2.20.1 in git://android.git.linaro.org/toolchain/binutils.git seems to be the same. I wonder where the reduced max page size is coming from?

[Mike Hommey (mh-glandium)]

Maybe something changed in the way the segments are aligned, now relying on the max page size, while it used not to?

[Bernhard Rosenkraenzer (berolinux)]

The binutils-2.20.1 in git://android.git.linaro.org/toolchain/binutils.git is from AOSP.

Their changes are described in the README.google file in the top level of that binutils tree -- however, the only changes listed there that aren't marked as upstreamed are unrelated ("g4 integrate CL 41851-p2 to implement dummy --icf option in ld" and "g4 integrate CL 28729-p2. Ignore --save-temps flag (to enable use of the GNU assembler with a compiler that passes --save-temps for MAO)."

Looks like they stopped documenting changes at some point (or started late) -- I'll look at real diff output rather than trusting their notes.

I don't have a problem with reducing the max page size, but I don't think increasing page size by itself should trigger this... Looks more like increasing the max page size shows a bug elsewhere that was just hidden by the combined bits being too large to fit in the reduced limits.

[Mike Hommey (mh-glandium)]

Oh I'm pretty sure it's something else that triggers this behaviour, as the previous patch changing the linker script did fix the problem without increasing the max page size. However, with that patch, I was hitting what very much looks like a bug in soslim. It also turns out that there indeed is a difference in segment alignment between android binutils and mainline binutils as the original message shows, despite the linker script requesting an alignment of 4096.

[Bernhard Rosenkraenzer (berolinux)]

This is fixed with the update to ICS (and the move to gold as part of the process).