This is the mail archive of the
mailing list for the binutils project.
Re: Linking against armlink produced ELF for armv6-m (thumb only) CPU
- From: Matthew Gretton-Dann <matthew dot gretton-dann at arm dot com>
- To: GusSabina <gussabina at yahoo dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 06 Jul 2011 14:15:22 +0100
- Subject: Re: Linking against armlink produced ELF for armv6-m (thumb only) CPU
- References: <4C5FEFEB.firstname.lastname@example.org> <email@example.com> <4C6021C8.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
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
On 05/07/11 18:49, GusSabina wrote:
I'm getting the same error...
What ARM Build attribute is explicitly causing this error? How should it be
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:
Principal Engineer - PDSW Tools
Principal Engineer, PD Software - Tools, ARM Ltd