Re: gcc and arm interworking

[Richard Earnshaw <rearnsha at arm dot com>]

> "Dave Murphy" <wintermute2k4@ntlworld.com> writes:
> 
> > I've built a mingw hosted arm-elf gcc toolchain & I'm having some problems
> > with interworking. It appears that when I link in a library compiled with
> > interworking enabled to an application which does not, the interworking bit
> > in the output elf is set. This causes problems when linking in standard
> > libraries - warnings are generated about the standard libraries not
> > supporting interworking while the elf does. Currently I'm not sure what's
> > causing this or why this should be the case.
> > 
> > Does anyone know what is setting the interwork bit and why?
> > 
> > this is with binutils 2.14, gcc 3.3.3 and newlib 1.12.0, compiled from the
> > respective release source tarballs.
> 
> The interworking flag is set by the assembler when gcc passes it the
> -mthumb-interwork option.
> 
> In the linker the function elf32_arm_merge_private_bfd_data() in
> elf32-arm.h is responsible for merging the flags of the input files
> into the output file.  I suspect that function is buggy.  In
> particular it seems to set the output flags based on the flags of the
> first input file that it sees.  For the INTERWORK flags it issues a
> warning, but does not go on to clear the flag from the output BFD as
> would seem to be appropriate.
> 
> That said, I think you are going to get a warning whenever you link
> interwork objects with non-interwork objects.  I don't have an opinion
> as to whether that is correct or not.
> 
> In any case, I believe this is a binutils issue, not a gcc issue.  The
> right mailing list is binutils@sources.redhat.com.  See
> http://sources.redhat.com/binutils/.

This is really the wrong list for this discussion (should really be on the 
binutils list), but here goes...

Non-interworking objects are only compatible with interworking objects if 
one of the following criteria are met:

1) All code is using the same instruction set (all ARM-state, or all 
Thumb-state)

Or:

2) Code compiled for interworking never calls a function that is not 
compiled for interworking.  In addition, if using indirect calls (pointers 
to functions) both must be interworking capable.

In general it's not possible to determine whether either of the above two 
criteria are met simply by looking at the object's attributes, so it's 
probably best to warn that things are incompatible.

R.