Creating ARM software FP object files from binary blobs

[Ivo Clarysse <ivo dot clarysse at gmail dot com>]

I'm attempting to include a link a binary blob in an ELF
executable using objcopy.

This works fine on Linux/x86, on Linux/arm I have problems
with hardware vs software floating-point:

$ arm_v4t_le-objcopy --input-target=binary
--binary-architecture=armv4t --output-target=elf32-littlearm
--rename-section .data=.rodata,alloc,load,readonly,data,contents
image.bin image.bin.o

$ arm_v4t_le-ld main.o image.bin.o
arm_v4t_le-ld: ERROR: image.bin.o uses hardware FP, whereas a.out uses
software FP
No such file or directory: failed to merge target specific data of
file image.bin.o


Indeed, the ELF object file created using objcopy does not have '[software FP]'
set in the ELF file header (and my target platform does use software FP):

$ arm_v4t_le-objdump -x image.bin.o

image.bin.o:???? file format elf32-littlearm
image.bin.o
architecture: arm, flags 0x00000010:
HAS_SYMS
start address 0x00000000
private flags = 0: [APCS-32] [FPA float format]

Sections:
Idx Name????????? Size????? VMA?????? LMA?????? File off? Algn
? 0 .rodata?????? 0000010e? 00000000? 00000000? 00000034? 2**0
????????????????? CONTENTS, ALLOC, LOAD, READONLY, DATA
SYMBOL TABLE:
00000000 l??? d? .rodata??????? 00000000
00000000 g?????? .rodata??????? 00000000 _binary_image_bin_start
0000010e g?????? .rodata??????? 00000000 _binary_image_bin_end
0000010e g?????? *ABS*? 00000000 _binary_image_bin_size


Whereas a file created by GCC for my platform does set '[software FP]':

$ arm_v4t_le-objdump -x main.o

main.o:???? file format elf32-littlearm
main.o
architecture: armv4t, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
private flags = 200: [APCS-32] [FPA float format] [software FP]

Sections:
Idx Name????????? Size????? VMA?????? LMA?????? File off? Algn
? 0 .text???????? 00000154? 00000000? 00000000? 00000034? 2**2
????????????????? CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
? 1 .data???????? 00000000? 00000000? 00000000? 00000188? 2**0
????????????????? CONTENTS, ALLOC, LOAD, DATA
? 2 .bss????????? 00000000? 00000000? 00000000? 00000188? 2**0
????????????????? ALLOC
? 3 .note.gnu.arm.ident 0000001c? 00000000? 00000000? 00000188? 2**0
????????????????? CONTENTS, READONLY, LINK_ONCE_SAME_CONTENTS
? 4 .rodata?????? 00000030? 00000000? 00000000? 000001a4? 2**2
????????????????? CONTENTS, ALLOC, LOAD, READONLY, DATA
? 5 .comment????? 0000003f? 00000000? 00000000? 000001d4? 2**0
????????????????? CONTENTS, READONLY
SYMBOL TABLE:
00000000 l??? df *ABS*? 00000000 main.c
00000000 l??? d? .text? 00000000
00000000 l??? d? .data? 00000000
00000000 l??? d? .bss?? 00000000
00000000 l??? d? .rodata??????? 00000000
00000000 l??? d? .note.gnu.arm.ident??? 00000000
00000000 l??? d? .comment?????? 00000000
[...]

(Also, ELF object files created with GCC cause objdump to report
'architecture: armv4t', whereas those created with objcopy
cause objdump to report 'architecture: arm', even though I did
specify? --binary-architecture=armv4t - but I'm unsure if this is
also an issue)


$ arm_v4t_le-objcopy --version
GNU objcopy 2.14 20030612 (MontaVista 2.14-11.0.4.0401541 2004-11-05)
$ arm_v4t_le-ld --version
GNU ld version 2.14 20030612 (MontaVista 2.14-11.0.4.0401541 2004-11-05)
$ arm_v4t_le-objdump --version
GNU objdump 2.14 20030612 (MontaVista 2.14-11.0.4.0401541 2004-11-05)
$ arm_v4t_le-gcc --version
arm_v4t_le-gcc (GCC) 3.3.1 (MontaVista 3.3.1-7.0.33.0501116 2005-07-21)


So, how do I instruct objcopy to create an ELF object file
with private flags 0x0200 instead of 0x0 ?

(For now, I've been able to work around this by passing the
'--no-warn-mismatch' option to the linker)


Best regards,

Ivo.