This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ld emitting blx immdetiate for Cortex M3


On Fri, Mar 16, 2012 at 03:19:15PM +0000, Benjamin Hase wrote:
<snip>
> arm-none-eabi-readelf -a toolchain-test.elf | grep FUNC
>     40: 000002f0     8 FUNC    LOCAL  DEFAULT    1 ____aeabi_idiv0_from_arm
>     46: 000001cc   252 FUNC    GLOBAL DEFAULT    1 __udivsi3
>     49: 000001ad    32 FUNC    GLOBAL DEFAULT    1 strtol
>     51: 00000039    16 FUNC    GLOBAL DEFAULT    1 _atoi_r
>     53: 000002e9     2 FUNC    WEAK   DEFAULT    1 __aeabi_ldiv0
>     54: 00000001    38 FUNC    GLOBAL DEFAULT    1 main
>     55: 000001cc     0 FUNC    GLOBAL DEFAULT    1 __aeabi_uidiv
>     56: 00000049   356 FUNC    GLOBAL DEFAULT    1 _strtol_r
>     58: 000002c8    32 FUNC    GLOBAL DEFAULT    1 __aeabi_uidivmod
>     62: 00000029    16 FUNC    GLOBAL DEFAULT    1 atoi
>     64: 000002e9     2 FUNC    WEAK   DEFAULT    1 __aeabi_idiv0
> 
> This tells me, that __aeabi_idiv0_from_arm, __udivsi3, __aeabi_uidiv and
> __aeabi_uidivmod are in ARM state, right?  That fits also with the output
> of objdump.

That is correct.

<snip>
> When looking at objects with arm-none-eabi-readelf -A, it looks like a
> toolchain problem for me (like you first suspected :-):
> 
> toolchain-test.elf:
> Attribute Section: aeabi
> File Attributes
>   Tag_CPU_name: "Cortex-M3"
>   Tag_CPU_arch: v7
>   Tag_CPU_arch_profile: Microcontroller
>   Tag_ARM_ISA_use: Yes
>   Tag_THUMB_ISA_use: Thumb-2
>   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 Debug
> 
> lib_a-strtol.o:
> Attribute Section: aeabi
> File Attributes
>   Tag_CPU_name: "ARM7TDMI"
>   Tag_CPU_arch: v4T
>   Tag_ARM_ISA_use: Yes
>   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 Speed
>   Tag_DIV_use: Not allowed
> 
> So I think the following is happening (please correct me, when I am wrong)
> - the linker starts with my application object, sees (by compiler option)
> architecture arm-v7
> - resolves atoi, strtol -> pulls lib_a-strtol.o
> - sees in lib_a-strtol.o architecture arm-v4t and enables ARM mode
> - arm-v4t does not know blx either, but since arm-v7 is already accepted
> (which can do blx), he is happy to change bl with blx

This is basically what the linker is doing.

However, you have shown a bug in the linker's output here:

> toolchain-test.elf:
> Attribute Section: aeabi
> File Attributes
>   Tag_CPU_name: "Cortex-M3"
>   Tag_CPU_arch: v7
>   Tag_CPU_arch_profile: Microcontroller
>   Tag_ARM_ISA_use: Yes
>   Tag_THUMB_ISA_use: Thumb-2

Cortex-M3 doesn't support ARM state instructions, but the linked image does.
The linker should output different attributes here (not least
Tag_CPU_arch_profile should not be 'Microcontroller').

Can you raise a bug in BugZilla please - giving the steps you take to get an
object/image with these attributes?

Thanks,

Matt

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]