linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: stefan@agner.ch (Stefan Agner)
To: linux-arm-kernel@lists.infradead.org
Subject: Bulid regression with VDSO enabled
Date: Thu, 30 Apr 2015 17:58:31 +0200	[thread overview]
Message-ID: <ec99281777f104866fbf49ec743eef2a@agner.ch> (raw)
In-Reply-To: <55424ED1.9030005@mentor.com>

On 2015-04-30 17:48, Nathan Lynch wrote:
> On 04/30/2015 10:20 AM, Stefan Agner wrote:
>> On 2015-04-30 16:38, Nathan Lynch wrote:
>>> On 04/30/2015 06:44 AM, Stefan Agner wrote:
>>>>   OBJCOPY arch/arm/vdso/vdso.so
>>>> BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try
>>>> linking with -N
>>>> arm-angstrom-linux-gnueabi-objcopy:arch/arm/vdso/vdso.so[.hash]: Bad
>>>> value
>>>> BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try
>>>> linking with -N
>>>> arm-angstrom-linux-gnueabi-objcopy:arch/arm/vdso/vdso.so: Bad value
>>>> make[2]: *** [arch/arm/vdso/vdso.so] Error 1
>>>> make[1]: *** [arch/arm/vdso] Error 2
>>>> make[1]: *** Waiting for unfinished jobs....
>>>>
>>>> I'm using GCC 4.8.3 (Linaro GCC 4.8-2014.04) on Fedora 21. Any specific
>>>> new requirements to the toolchain or a bug?
>>>
>>> I've not encountered this before, and I'm not able to recreate it with
>>> that toolchain.
>>>
>>> If you're using the Linaro toolchain I would expect the name of objcopy
>>> to be arm-linux-gnueabihf-objcopy, but your log shows
>>> arm-angstrom-linux-gnueabi-objcopy.  What's going on there?
>>
>> The toolchain is built by the OpenEmbedded build system. I used the
>> Angstrom distribution, which uses the Linaro Layer (daisy branch) which
>> built that toolchain:
>> https://git.linaro.org/openembedded/meta-linaro.git/shortlog/refs/heads/daisy
>>
>> I tried the official release and I also could not reproduce the issue,
>> so it seems to be toolchain related...?
> 
> Okay thanks, that gives me more to go on.  I probably won't be able to
> devote more time to this today, but hopefully tomorrow.

FWIW, I just looked into it a bit more myself, however don't understand
what is wrong with that toolchain so far. The generated linker command
looks good for both toolchains, it is really that one linker creates the
problem with the very same arguments while the other does not.

The toolchain generated by OpenEmbedded is probably quite different from
the official releases. There are a bunch of configurations which are
tweaked depending on the local OE configuration as well:
https://github.com/openembedded/oe-core/blob/master/meta/recipes-devtools/gcc/gcc-configure-common.inc

I also dumped the headers of the working/non-working output file, there
seem to be different sections generated, maybe a hint?

ags at linuxdev /tmp $
/tmp/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-objdump
-h /tmp/vdso.so.raw.working

/tmp/vdso.so.raw.working:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .hash         00000028  000000d4  000000d4  000000d4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .dynsym       00000050  000000fc  000000fc  000000fc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .dynstr       00000044  0000014c  0000014c  0000014c  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .gnu.version  0000000a  00000190  00000190  00000190  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .gnu.version_d 00000038  0000019c  0000019c  0000019c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .note         00000024  000001d4  000001d4  000001d4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .dynamic      00000080  000001f8  000001f8  000001f8  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  7 .ARM.exidx    00000028  00000278  00000278  00000278  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .text         0000042c  000002a0  000002a0  000002a0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  9 .got.plt      0000000c  000006cc  000006cc  000006cc  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 10 .comment      0000003a  00000000  00000000  000006d8  2**0
                  CONTENTS, READONLY
 11 .ARM.attributes 0000002f  00000000  00000000  00000712  2**0
                  CONTENTS, READONLY
ags at linuxdev /tmp $
/tmp/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-objdump
-h /tmp/vdso.so.raw 

/tmp/vdso.so.raw:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .hash         00000028  000000b4  000000b4  000000b4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .dynsym       00000050  000000dc  000000dc  000000dc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .dynstr       0000004b  0000012c  0000012c  0000012c  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .gnu.version  0000000a  00000178  00000178  00000178  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .gnu.version_d 00000038  00000184  00000184  00000184  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .note         00000040  000001bc  000001bc  000001bc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .dynamic      00000088  000001fc  000001fc  000001fc  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  7 .ARM.extab    00000000  00000284  00000284  00000284  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .ARM.exidx    00000028  00000284  00000284  00000284  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .interp       00000013  000002ac  000002ac  000002ac  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .text         0000042c  000002c0  000002c0  000002c0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 11 .comment      0000003b  00000000  00000000  000006ec  2**0
                  CONTENTS, READONLY
 12 .ARM.attributes 0000002f  00000000  00000000  00000727  2**0
                  CONTENTS, READONLY


--
Stefan

  reply	other threads:[~2015-04-30 15:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-30 11:44 Bulid regression with VDSO enabled Stefan Agner
2015-04-30 14:38 ` Nathan Lynch
2015-04-30 15:20   ` Stefan Agner
2015-04-30 15:48     ` Nathan Lynch
2015-04-30 15:58       ` Stefan Agner [this message]
2015-05-01 15:22         ` Nathan Lynch
     [not found]           ` <5548F302.5040909@mentor.com>
2015-05-05 17:27             ` support status of gold (was: Bulid regression with VDSO enabled) Russell King - ARM Linux
2015-05-05 17:28             ` Ard Biesheuvel
     [not found] <391d6fc127b78ef4cbc5443557f0665a@agner.ch>
2015-05-08 11:28 ` Bulid regression with VDSO enabled Russell King - ARM Linux
2015-05-08 12:23   ` Stefan Agner
2015-05-08 15:27 ` Nathan Lynch
2015-05-08 16:08   ` Stefan Agner
2015-05-08 21:15     ` Nathan Lynch
2015-05-09  8:31       ` Ard Biesheuvel
2015-05-11 14:18         ` Nathan Lynch
2015-05-09  9:26       ` Russell King - ARM Linux
2015-05-15 17:01         ` Nathan Lynch
2015-05-09 12:41       ` Stefan Agner
2015-05-09 13:25         ` Stefan Agner
2015-05-11 14:27           ` Nathan Lynch
2015-05-09  9:32     ` Russell King - ARM Linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ec99281777f104866fbf49ec743eef2a@agner.ch \
    --to=stefan@agner.ch \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).