This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Bug: Core dump in elf32-arm.c:3858:bfd_elf32_arm_vfp11_fix_veneer_locations arm-elf-ld 2.18
Hi Shaun,
The bug does occur in binutils 2.16.1. The bug does not occur in
binutils 2.17. The bug does occur in binutils 2.18. The bug does not
occur in today's CVS. Did you follow all that? =P
Yup. This is actually pretty much what I expected you would find. We
recently added code to the CVS repository which I suspected would fix
this problem.
Since it's fixed in current CVS, all should be well
except for one detail: the warning "unknown architecture of input file
`data.o' is incompatible with arm output" seems to have been promoted
from a warning in 2.17 to an error in the current CVS.
Yes. This is because of the bug you encountered. Basically what is
going on is that when the linker loads in an ARM object file, it
allocates some extra, arm-specific fields in one of its data structures.
These fields are necessary in order to complete the link, hence if a
non-arm object file is included in the link, (and the arm-specific
fields are not allocated) then the link cannot be relied upon to
complete properly. (If this non-arm object file is just data then the
link will probably work, but there is no way to guarantee it). So the
linker now generates an error, so that the user is forced to address the
problem in some way.
I can use the -B,--binary-architecture option to objcopy to suppress
this warning:
$ arm-elf-objcopy -Ibinary -Oelf32-littlearm -Barm data data.o
but since the data file does not contain ARM instructions, using -Barm
does not seem the right solution.
The recommended way to solve this problem is use the assembler to insert
the binary data into a normal section and the output an arm object file,
like this:
% cat foo.s
.data
label_at_start_of_binary:
.incbin "data"
% arm-elf-gas foo.s -o foo.o
% arm-elf-ld .... foo.o ....
Cheers
Nick