This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: How to identify Arch info when building
- From: naveen yadav <yad dot naveen at gmail dot com>
- To: Matthew Gretton-Dann <matthew dot gretton-dann at linaro dot org>
- Cc: gcc-help at gnu dot org, binutils at sourceware dot org
- Date: Wed, 31 Oct 2012 19:27:50 +0530
- Subject: Re: How to identify Arch info when building
- References: <CAJ8eaTwYd-6sevA0B_44K3vk7xSgFspcpL6YU6H52y8wCB=Xng@mail.gmail.com> <CADSXKXrMa8xoPrOc7GpTx2PNRfw+b3f0cYm+8VHVKKoVP+yUYg@mail.gmail.com>
Thanks Matthew for your suggestion,
the o/p is from linux-gnueabi-readelf -A .
and what you suggest is what we want. At link time we should get error
of mistmatch.
>What you may be able to do (and I make no guarantees here) is add a
> stage to your build which checks the attributes on the generated .so
> after link to make sure that they match what you want.
so is there any way at link time I can verify that a particular .so or
.o is compile with different(ARM9), when build for A15.
Thanks
On Wed, Oct 31, 2012 at 7:11 PM, Matthew Gretton-Dann
<matthew.gretton-dann@linaro.org> wrote:
> This is a linker issue, and best asked on binutils@sourceware.org.
>
> On 31 October 2012 12:58, naveen yadav <yad.naveen@gmail.com> wrote:
>> Hi All,
>>
>> I have two ARM arch (A9 and A15). and have cross compiler for both.
>>
>> Since code is integrated, some time .so got mixed(A9 with A15), and at
>> run time it fails with undefined instruction.
>>
>> Is there any way to check strict at build time, we through an error.
>>
>> Scenario.
>>
>> (A15 code) + A9(.so)= executable when run on target (undefined instruction)
>>
>> Tag_CPU_name: "Cortex-A15"
>> Tag_CPU_arch: v7
>> Tag_CPU_arch_profile: Application
>> Tag_ARM_ISA_use: Yes
>>
>>
>> Tag_CPU_name: "Cortex-A9"
>> Tag_CPU_arch: v7
>> Tag_CPU_arch_profile: Application
>
> It is unclear where the different attributes above are coming from.
>
> The linker's checking for incompatibilities between objects is
> restricted to examples like 'size of wchar_t == 2' is incompatible
> with 'size of wchar_t == 4'. In this case it is obvious that these
> two objects will never work together.
>
> When it encounters two objects where one uses features that are not
> used in another (as for instance if you link objects for Cortex-A9
> which doesn't have integer-divide, and objects for Cortex-A15 which
> does) the linker assumes the user wants to run the code on the most
> 'feature'-ful.
>
> There is no way to tell the linker which CPU you intend to run the code on.
>
> What you may be able to do (and I make no guarantees here) is add a
> stage to your build which checks the attributes on the generated .so
> after link to make sure that they match what you want.
>
> Thanks,
>
> Matt
>
> --
> Matthew Gretton-Dann
> Linaro Toolchain Working Group
> matthew.gretton-dann@linaro.org