Linking against armlink produced ELF for armv6-m (thumb only) CPU

Linking against armlink produced ELF for armv6-m (thumb only) CPU

[Heikki Keränen]

Hi,

I have found no good solution to this problem. Can anyone help?

We have a ROM image produced by RVCT toolchain: armlink produces .axf
-file which is in ELF-format. Now we would like to create an executable
to the RAM by using the GNU-toolchain. Those RAM-executables should of
course link against functions in ROM.

If I have understood everything right the correct way to do this is to
link against this armlink produced ELF-file by using option
"--just-symbols=romimagefile.elf".

Everything works when I link against a ROM image ELF-file produced by
the ld -linker, but when I link against armlink -produced ELF-file the
following happens:

Build finishes, but in the ld -linker prints out a following error
message: "Conflicting CPU architectures 11/0". Also the veneers
generated by the ld -linker seem to contain ARM-instructions although we
have a thumb-only CPU architecture (armv6-m).

Binutils ld -linker does not seem to have any command line options to
select or force certain arm-architecture like armlink does. If I
understood right, it is doing the guessing based on the .ARM.attributes
-sections in the input files. I have examined differences in the ld and
armlink produced ELF-files and it seems that armlink does not put
.ARM.attributes -section into the ELF-file like ld does. When the
.ARM.attributes -section is missing the ld -linker assumes the
architecture of that file is "TAG_CPU_ARCH_PRE_V4" (which equals 0 in
arm.h), and generates veneers according to that. And of course our
thumb-only CPU raises an exception when it meets an arm instruction in
the veneer.

Because I have found no way to enable armlink to generate
.ARM.attributes -section to the ELF-file and ld does not work in the
desired way without this information I'am in a dead end.

To work around the problem I have tried to copy an .ARM.attributes
-section from ld generated ELF to armlink generated ELF by using
binutils objcopy with option --add-section, but I have found no way to
set the section type to ARM_ATTRIBUTES, which seems to be required by
the ld -linker.

I have also tried to refer to the ROM symbols by introducing them in a
linker script -file, but the problem is that there is no way to tell ld
that these symbols refer to thumb-code and again the linker is
generating veneers containing arm instructions.

The binutils I'am using is a self compiled CVS snapshot:
"GNU ld (GNU Binutils) 2.20.51.20100802"

The only way I have managed to create a working executable is to modify
the ld -linkers 'using_thumb_only' -function in elf32-arm.c to return
always true, which of course is not an sustainable solution in the long
term.

Is there something I have not found by myself I could try or is this
problem right now a compatibility problem with no solution?

What would be the best solution in the long term?

	Heikki K.

Re: Linking against armlink produced ELF for armv6-m (thumb only) CPU

[Matthew Gretton-Dann]

Hi,

On Mon, 2010-08-09 at 15:09 +0300, Heikki Keränen wrote:
> Hi,
> 
> I have found no good solution to this problem. Can anyone help?
> 
> We have a ROM image produced by RVCT toolchain: armlink produces .axf
> -file which is in ELF-format. Now we would like to create an executable
> to the RAM by using the GNU-toolchain. Those RAM-executables should of
> course link against functions in ROM.
> 
> If I have understood everything right the correct way to do this is to
> link against this armlink produced ELF-file by using option
> "--just-symbols=romimagefile.elf".
> 
> Everything works when I link against a ROM image ELF-file produced by
> the ld -linker, but when I link against armlink -produced ELF-file the
> following happens:
> 
> Build finishes, but in the ld -linker prints out a following error
> message: "Conflicting CPU architectures 11/0". Also the veneers
> generated by the ld -linker seem to contain ARM-instructions although we
> have a thumb-only CPU architecture (armv6-m).

Can you give some sample command lines (I don't think objects are
necessary at the moment) please?

What I am looking for are examples of how you call armcc, armlink, gcc,
and ld.

Can you also give the results of readelf -A when run on the armlink
produced image and also one of the gcc produced objects you are trying
to link against?

What version of RVCT are you using (what is the result of armlink
--vsn)?

[snip]

> Is there something I have not found by myself I could try or is this
> problem right now a compatibility problem with no solution?

I don't have enough information at the moment to be able to make a call
as to what the cause of this issue is.

> What would be the best solution in the long term?

If you can answer the questions above we might be able to give a good
answer to your question.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer - PDSW Tools
ARM Ltd

Re: Linking against armlink produced ELF for armv6-m (thumb only) CPU

[Heikki Keränen]

On 9.8.2010 15:39, Matthew Gretton-Dann wrote:
> Hi,
> 
> On Mon, 2010-08-09 at 15:09 +0300, Heikki Keränen wrote:
>> Hi,
>>
>> I have found no good solution to this problem. Can anyone help?
>>
>> We have a ROM image produced by RVCT toolchain: armlink produces .axf
>> -file which is in ELF-format. Now we would like to create an executable
>> to the RAM by using the GNU-toolchain. Those RAM-executables should of
>> course link against functions in ROM.

[snip]

>> Build finishes, but in the ld -linker prints out a following error
>> message: "Conflicting CPU architectures 11/0". Also the veneers
>> generated by the ld -linker seem to contain ARM-instructions although we
>> have a thumb-only CPU architecture (armv6-m).
> 
> Can you give some sample command lines (I don't think objects are
> necessary at the moment) please?


Here is my very simple example project I used to reproduce this issue:

----- simple_rom_rvct\simple_rom.h ---------
#ifndef SIMPLE_ROM_H
#define SIMPLE_ROM_H

int simple_rom_function(int param);

#endif // SIMPLE_ROM_H
-------------------------------------------

---- simple_rom_rvct\simple_rom.c ----------
#include "simple_rom.h"

int simple_rom_function(int param)
{
	return param + 1;
}
-------------------------------------------

----- simple_ram\simple_ram.c -------------
#include "../simple_rom/simple_rom.h"

int mainfunction(void)
{
	int result;
	result = simple_rom_function(1);
	return result;
}
------------------------------------------

----- simple_ram\simple_ram.ld -----------
MEMORY
{
    MYROM (rx) : ORIGIN = 0x10000000, LENGTH = 0x00008000
    MYRAM (rwxa) : ORIGIN = 0x30000000, LENGTH = 0xf0000000
}

SECTIONS
{
  .text : { *(.text) } >MYRAM
  .data : { *(.data) } >MYRAM
  .bss :  { *(.bss)  } >MYRAM
}
--------------------------------------------


> 
> What I am looking for are examples of how you call armcc, armlink, gcc,
> and ld.

------  RVCT build output (form uVision IDE) -------
Build target 'Target 1'
compiling simple_rom.c...
simple_rom.c: [ArmCC --show_cmdline --debug -c -osimple_rom.o
--depend=simple_rom.d --cpu=Cortex-M0 --apcs=interwork -O0
-IC:\Keil\ARM\INC -IC:\Keil\ARM\INC\ARM --omf_browse=simple_rom.crf
simple_rom.c]
linking...
simple_rom.axf: [ArmLink --show_cmdline --strict
--diag_suppress=6320,6305 --ro_base=0x0 --rw_base=0x0 --cpu=Cortex-M0
--first=__Vectors --output=simple_rom.axf --entry=Reset_Handler
--keep=.ARM.attributes --info=summarysizes simple_rom.o]
Program Size: Code=8 RO-data=0 RW-data=0 ZI-data=0
FromELF: creating hex file...
"simple_rom.axf" - 0 Error(s), 0 Warning(s).
----------------------------------------------------


------- GNU toolchain output (from Eclipse) -------
make all
Building file: simple_ram.c
Invoking: arm-none-eabi-gcc C Compiler
arm-none-eabi-gcc -Os -Wall -c -fmessage-length=0 -MD -MF"simple_ram.d"
-MT"simple_ram.d" -mcpu=cortex-m0 -fpic -mthumb -o"simple_ram.o"
"simple_ram.c"
Finished building: simple_ram.c

Building target: simple_ram.elf
Invoking: arm-none-eabi-gcc C Linker
arm-none-eabi-gcc -T"simple_ram.ld" -nostartfiles
-Wl,--architecture=armv6-m --pic-executable -mcpu=cortex-m0
--strip-debug  -o"simple_ram.elf"  ./simple_ram.o
-Wl,--just-symbols=../simple_rom_rvct/simple_rom.axf
c:/msys/1.0/home/heikki/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/4.5.0/../../../../arm-none-eabi/bin/ld.exe:
error: ../simple_rom_rvct/simple_rom.axf: Conflicting CPU architectures 11/0
Finished building target: simple_ram.elf
-------------------------------------------------

> 
> Can you also give the results of readelf -A when run on the armlink
> produced image and also one of the gcc produced objects you are trying
> to link against?

D:\simple_rom_rvct>arm-none-eabi-readelf -A simple_rom.axf

  < NOTE: no output here, since .axf does not contain .ARM.attributes? >

D:\simple_ram>arm-none-eabi-readelf -A simple_ram.o
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "CORTEX-M0"
  Tag_CPU_arch: v6-M
  Tag_CPU_arch_profile: Microcontroller
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: small
  Tag_ABI_optimization_goals: Aggressive Size
  Tag_DIV_use: Not allowed

> 
> What version of RVCT are you using (what is the result of armlink
> --vsn)?

ARM Linker, RVCT4.0 [Build 728] [Standard]

[snip]

> If you can answer the questions above we might be able to give a good
> answer to your question.
> 
> Thanks,
> 
> Matt

Here should be all the information you asked. I can provide additional
details if required. I have tried a large number of compiler and linker
options so some of those options I used are probably unnecessary or stupid.

Thanks for taking a look into this issue,

	Heikki K.

Re: Linking against armlink produced ELF for armv6-m (thumb only) CPU

[Matthew Gretton-Dann]

On Mon, 2010-08-09 at 18:42 +0300, Heikki Keränen wrote:
> 
> On 9.8.2010 15:39, Matthew Gretton-Dann wrote:
> > Hi,
> > 
> > On Mon, 2010-08-09 at 15:09 +0300, Heikki Keränen wrote:
> >> Hi,
> >>
> >> I have found no good solution to this problem. Can anyone help?
> >>
> >> We have a ROM image produced by RVCT toolchain: armlink produces .axf
> >> -file which is in ELF-format. Now we would like to create an executable
> >> to the RAM by using the GNU-toolchain. Those RAM-executables should of
> >> course link against functions in ROM.
> 
> [snip]
> 
> >> Build finishes, but in the ld -linker prints out a following error
> >> message: "Conflicting CPU architectures 11/0". Also the veneers
> >> generated by the ld -linker seem to contain ARM-instructions although we
> >> have a thumb-only CPU architecture (armv6-m).
> > 
> > Can you give some sample command lines (I don't think objects are
> > necessary at the moment) please?
> 
> 
> Here is my very simple example project I used to reproduce this issue:
[test case snipped]

> Here should be all the information you asked. I can provide additional
> details if required. I have tried a large number of compiler and linker
> options so some of those options I used are probably unnecessary or stupid.

Thank you for the test case - I have managed to reproduce the behaviour
you are seeing, and also cut it down to a test case that only needs gas
and ld to exhibit the same behaviour.

The basic issue seems to be that we are treating an object with
no .ARM.attributes section as one where all the attributes take their
default value (0 or "") and not one which has all the attributes set to
undefined (as if a TAG_nodefaults attribute was present).

I have raised the following bug in BugZilla to address this:
http://sourceware.org/bugzilla/show_bug.cgi?id=11897

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer - PDSW Tools
ARM Ltd

Re: Linking against armlink produced ELF for armv6-m (thumb only) CPU

[GusSabina]

Hello Matthew:

I'm getting the same error...
What ARM Build attribute is explicitly causing this error? How should it be
fixed?

Thanks
Gus


Matthew Gretton-Dann-2 wrote:
> 
> On Mon, 2010-08-09 at 18:42 +0300, Heikki Keränen wrote:
>> 
> 
> The basic issue seems to be that we are treating an object with
> no .ARM.attributes section as one where all the attributes take their
> default value (0 or "") and not one which has all the attributes set to
> undefined (as if a TAG_nodefaults attribute was present).
> 
> I have raised the following bug in BugZilla to address this:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11897
> 
> Thanks,
> 
> Matt
> 
> -- 
> Matthew Gretton-Dann
> Principal Engineer - PDSW Tools
> ARM Ltd
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/Linking-against-armlink-produced-ELF-for-armv6-m-%28thumb-only%29-CPU-tp29387210p31998893.html
Sent from the Sourceware - binutils list mailing list archive at Nabble.com.

Re: Linking against armlink produced ELF for armv6-m (thumb only) CPU

[Matthew Gretton-Dann]

Hi,

The root cause of the issue is that the linker is assuming the wrong 
defaults for an object which does not have a .ARM.attributes section.

There is no one particular build attribute causing the error, it is the 
defaults ld assumes.

One workaround may be to strip all the .ARM.attributes sections out of 
the objects before passing them to the linker:
   arm-none-eabi-objcopy -R '.ARM.attributes' tst.o -o tst.stripped.o

Thanks,

Matt

On 05/07/11 18:49, GusSabina wrote:
>
> Hello Matthew:
>
> I'm getting the same error...
> What ARM Build attribute is explicitly causing this error? How should it be
> fixed?
>
> Thanks
> Gus
>
>
> Matthew Gretton-Dann-2 wrote:
>>
>> On Mon, 2010-08-09 at 18:42 +0300, Heikki Keränen wrote:
>>>
>>
>> The basic issue seems to be that we are treating an object with
>> no .ARM.attributes section as one where all the attributes take their
>> default value (0 or "") and not one which has all the attributes set to
>> undefined (as if a TAG_nodefaults attribute was present).
>>
>> I have raised the following bug in BugZilla to address this:
>> http://sourceware.org/bugzilla/show_bug.cgi?id=11897
>>
>> Thanks,
>>
>> Matt
>>
>> --
>> Matthew Gretton-Dann
>> Principal Engineer - PDSW Tools
>> ARM Ltd
>>
>>
>>
>


-- 
Matthew Gretton-Dann
Principal Engineer, PD Software - Tools, ARM Ltd

Re: Linking against armlink produced ELF for armv6-m (thumb only) CPU

[Matthew Gretton-Dann]

[Re-including binutils@sourceware.org on cc-list].

On 12/07/11 06:24, Gus Sabina wrote:
> Hello Matthew:
> Thanks for your response. Actually, I didn't not include any
> .ARM.attributes section at all but I'm still getting the "Conflicting
> CPU architectures 0/11" error.

What target was gas configured for?  To find this out do:
	.../as --version

.ARM.attributes sections  are only supported for EABI targets 
(arm*-*-*eabi) and not for the older ELF targets (for instance 
arm-none-elf).

As you seem to be trying to link against objects which have been 
assembled targeting the EABI you should ensure your assembler is using 
an EABI target.

> Let me explain what I'm doing. I 'm creating a tool which goal is to
> create some "pattern" which should be located somewhere in memory (where
> the linker decides it). I'm not using a compiler so I'm creating the
> object file directly. So, I'm creating all sections (.emb_text including
> the pattern). The problem is that when I link my object file with the
> embedded system project, I'm getting the above error... It still works
> but I would really like to get rid of this error...
> My question is, should I include an .ARM.attributes to avoid this, and
> if so, which would be the most appropriate?

When targeting EABI targets gas will automatically generate an 
.ARM.attributes section.  It will 'guess' the values to put in this 
section from the command-line options you specify (in particular -mcpu, 
-mfpu, -march).  You can also specify other attributes by using the 
.eabi_attribute directive (see 
http://sourceware.org/binutils/docs-2.21/as/ARM-Directives.html#ARM-Directives 
for documentation).

A fuller description of attributes is available in the ARM EABI 
documentation here:
     http://infocenter.arm.com/help/topic/com.arm.doc.ihi0045c/index.html

I can't tell you which directives to use.  The general guidance is that 
they should reflect your intentions as to what CPUs you expect the code 
to be run on.

> I'm attaching an example of the object file I'm creating so you can
> inspect it.
> I would really appreciate if you can help me with this issue...

I hope the above helps.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer, PD Software - Tools, ARM Ltd