diff mbox

linker problem with xip kernel and recent toolchains

Message ID 50BE0CDB.5000704@pengutronix.de (mailing list archive)
State New, archived
Headers show

Commit Message

Marc Kleine-Budde Dec. 4, 2012, 2:46 p.m. UTC
Hello,

we've just discovered a linker problem with newer toolchains, that
support --build-id and xip kernels. The resulting vmlinux is about 13
MiB big, but the xipimage ~2GiB.

A look at the vmlinux's objdump shows that the .notes section is around
2 GiB and it's placed by the linker script into the RAM. With the ROM
starting at 0x0 this results into a ~2 GiB big image.

>   [16] .data             PROGBITS        88008000 0a0000 012aa0 00  WA  0   0 256
>   [17] .notes            NOTE            8801aaa0 0b2aa0 000024 00  AX  0   0  4
>   [18] .bss              NOBITS          8801aae0 0b2ac4 005414 00  WA  0   0 32

After discarding the .notes section in the objcopy (see patch below) the
resulting binary images has a proper size again.

Marc

index 1ec5f67..4448790 100644

Comments

Pawel Moll Dec. 11, 2012, 1:01 p.m. UTC | #1
Hi Marc,

On Tue, 2012-12-04 at 14:46 +0000, Marc Kleine-Budde wrote:
> we've just discovered a linker problem with newer toolchains, that
> support --build-id and xip kernels. The resulting vmlinux is about 13
> MiB big, but the xipimage ~2GiB.
> 
> A look at the vmlinux's objdump shows that the .notes section is around
> 2 GiB and it's placed by the linker script into the RAM. With the ROM
> starting at 0x0 this results into a ~2 GiB big image.
> 
> >   [16] .data             PROGBITS        88008000 0a0000 012aa0 00  WA  0   0 256
> >   [17] .notes            NOTE            8801aaa0 0b2aa0 000024 00  AX  0   0  4
> >   [18] .bss              NOBITS          8801aae0 0b2ac4 005414 00  WA  0   0 32
> 
> After discarding the .notes section in the objcopy (see patch below) the
> resulting binary images has a proper size again.

Could you please send me the configuration you're using to get the XIP
kernel? I'll try to get my head around this problem and check how other
architectures are dealing with the problem.

Thanks!

Pawe?
Marc Kleine-Budde Dec. 11, 2012, 1:43 p.m. UTC | #2
On 12/11/2012 02:01 PM, Pawel Moll wrote:
> On Tue, 2012-12-04 at 14:46 +0000, Marc Kleine-Budde wrote:
>> we've just discovered a linker problem with newer toolchains, that
>> support --build-id and xip kernels. The resulting vmlinux is about 13
>> MiB big, but the xipimage ~2GiB.
>>
>> A look at the vmlinux's objdump shows that the .notes section is around
>> 2 GiB and it's placed by the linker script into the RAM. With the ROM
>> starting at 0x0 this results into a ~2 GiB big image.
>>
>>>   [16] .data             PROGBITS        88008000 0a0000 012aa0 00  WA  0   0 256
>>>   [17] .notes            NOTE            8801aaa0 0b2aa0 000024 00  AX  0   0  4
>>>   [18] .bss              NOBITS          8801aae0 0b2ac4 005414 00  WA  0   0 32
>>
>> After discarding the .notes section in the objcopy (see patch below) the
>> resulting binary images has a proper size again.
> 
> Could you please send me the configuration you're using to get the XIP
> kernel? I'll try to get my head around this problem and check how other
> architectures are dealing with the problem.

What about putting the notes section into the read only segment, i.e.
the ROM?

.config is attached. It's against 3.6.10 + some patches. The problem
does not occur with our uclibc based toolchain, which doesn't crate a
.notes section, but it still happens with a newlib based one.

> ${CROSS_COMPILE}gcc -v
> Using built-in specs.
> COLLECT_GCC=/home/mol/vcs/OSELAS.Toolchain-2011.02/inst.keep/opt/OSELAS.Toolchain-2011.11.0/arm-cortexm3-eabi/gcc-4.7.2-newlib-1.19.0-binutils-2.22/bin/arm-cortexm3-eabi-gcc
> COLLECT_LTO_WRAPPER=/home/mol/vcs/OSELAS.Toolchain-2011.02/inst.keep/opt/OSELAS.Toolchain-2011.11.0/arm-cortexm3-eabi/gcc-4.7.2-newlib-1.19.0-binutils-2.22/bin/../libexec/gcc/arm-cortexm3-eabi/4.7.2/lto-wrapper
> Target: arm-cortexm3-eabi
> Configured with: /home/mol/vcs/OSELAS.Toolchain-2011.02/platform-arm-cortexm3-eabi-gcc-4.7.2-newlib-1.19.0-binutils-2.22/build-cross/gcc-4.7.2/configure --build=x86_64-host-linux-gnu --host=x86_64-host-linux-gnu --target=arm-cortexm3-eabi --enable-multilib --with-float=soft --with-fpu=vfp --with-cpu=cortex-m3 --with-mode=thumb --with-newlib --disable-__cxa_atexit --enable-sjlj-exceptions --disable-nls --disable-decimal-float --disable-fixed-point --disable-win32-registry --enable-symvers=gnu --with-pkgversion=OSELAS.Toolchain-2011.11.0 --enable-threads=single --with-system-zlib --with-gmp=/home/mol/vcs/OSELAS.Toolchain-2011.02/platform-arm-cortexm3-eabi-gcc-4.7.2-newlib-1.19.0-binutils-2.22/sysroot-host --with-mpfr=/home/mol/vcs/OSELAS.Toolchain-2011.02/platform-arm-cortexm3-eabi-gcc-4.7.2-newlib-1.19.0-binutils-2.22/sysroot-host --prefix=/home/mol/vcs/OSELAS.Toolchain-2011.02/inst/opt/OSELAS.Toolchain-2011.11.0/arm-cortexm3-eabi/gcc-4.7.2-newlib-1.19.0-binutils-2.22 --enable-langua
ges=c --enable-c99 --enable-long-long --enable-libstdcxx-debug --enable-profile --disable-shared --disable-libssp --enable-checking=release
> Thread model: single
> gcc version 4.7.2 (OSELAS.Toolchain-2011.11.0)

Here the readelf output:

ROM starts at 0x0
RAM starts at 88008000

> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
>   [ 1] .bootloader       PROGBITS        00000000 008000 000300 00  AX  0   0  8
>   [ 2] .head.text        PROGBITS        00000300 008300 00004c 00  AX  0   0  4
>   [ 3] .text             PROGBITS        00000360 008360 077844 00  AX  0   0 32
>   [ 4] .text.init        PROGBITS        00077ba4 07fba4 00009c 00  AX  0   0  4
>   [ 5] .rodata           PROGBITS        00078000 080000 00d9c8 00   A  0   0 32
>   [ 6] __param           PROGBITS        000859c8 08d9c8 0000a0 00   A  0   0  4
>   [ 7] __modver          PROGBITS        00085a68 08da68 000598 00   A  0   0  4
>   [ 8] .ARM.unwind_idx   ARM_EXIDX       00086000 08e000 000040 00  AL  3   0  4
>   [ 9] .init.text        PROGBITS        00086040 08e040 006b28 00  AX  0   0  8
>   [10] .exit.text        PROGBITS        0008cb68 094b68 0001f0 00  AX  0   0  4
>   [11] .init.proc.info   PROGBITS        0008cd58 094d58 000054 00  AX  0   0  2
>   [12] .init.arch.info   PROGBITS        0008cdac 094dac 000044 00   A  0   0  4
>   [13] .init.tagtable    PROGBITS        0008cdf0 094df0 000040 00   A  0   0  4
>   [14] .init.data        PROGBITS        0008ce30 094e30 000388 00  WA  0   0  4
>   [15] .data             PROGBITS        88008000 098000 012aa0 00  WA  0   0 256
>   [16] .notes            NOTE            8801aaa0 0aaaa0 000024 00   A  0   0  4
>   [17] .bss              NOBITS          8801aae0 0aaac4 005414 00  WA  0   0 32
>   [18] .comment          PROGBITS        00000000 0aaac4 000028 01  MS  0   0  1
>   [19] .ARM.attributes   ARM_ATTRIBUTES  00000000 0aaaec 00002b 00      0   0  1
>   [20] .debug_line       PROGBITS        00000000 0aab17 098048 00      0   0  1
>   [21] .debug_info       PROGBITS        00000000 142b5f 88b2f3 00      0   0  1
>   [22] .debug_abbrev     PROGBITS        00000000 9cde52 06a5dc 00      0   0  1
>   [23] .debug_aranges    PROGBITS        00000000 a38430 003b20 00      0   0  8
>   [24] .debug_ranges     PROGBITS        00000000 a3bf50 0296e0 00      0   0  8
>   [25] .debug_frame      PROGBITS        00000000 a65630 025388 00      0   0  4
>   [26] .debug_str        PROGBITS        00000000 a8a9b8 03ef39 01  MS  0   0  1
>   [27] .debug_loc        PROGBITS        00000000 ac98f1 169767 00      0   0  1
>   [28] .shstrtab         STRTAB          00000000 c33058 000141 00      0   0  1
>   [29] .symtab           SYMTAB          00000000 c33674 03bf70 10     30 11065  4
>   [30] .strtab           STRTAB          00000000 c6f5e4 0205da 00      0   0  1

I can put the kernel patches and the toolchain on our ftp for download.

Marc
Pawel Moll Dec. 11, 2012, 1:52 p.m. UTC | #3
On Tue, 2012-12-11 at 13:43 +0000, Marc Kleine-Budde wrote:
> What about putting the notes section into the read only segment, i.e.
> the ROM?

Yes, this is probably a good idea. I'll see to it, thanks!

Pawe?
diff mbox

Patch

--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -18,7 +18,7 @@  ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
 LDFLAGS_vmlinux        += --be8
 endif

-OBJCOPYFLAGS   :=-O binary -R .comment -S
+OBJCOPYFLAGS   :=-O binary -R .comment -R .notes -S
 GZFLAGS                :=-9
 #KBUILD_CFLAGS +=-pipe