Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc)

[Julian Brown <julian at codesourcery dot com>]

Richard Earnshaw wrote:
> On Wed, 2005-03-16 at 16:10, Ian Lance Taylor wrote:
>
> > Julian Brown <julian@codesourcery.com> writes:
> >
> >
> > > Would it be better to add a --target-arch (or something) flag to
> > > binutils at this point? That would tidy up a previous patch of mine,
> > > too. I don't know if any other targets have, or need, such an option.
> >
> > I think the linker should support a command line option to do what
> > OUTPUT_ARCH does in a linker script.  
>
>
> I'm not convinced, but then I'm not entirely sure what OUTPUT_ARCH
> does.  
>
> It appears that OUTPUT_ARCH uses bfd variant names, but the problem is
> that in the past this has worked by (ab)using bits in the ELF header
> which simply aren't available in the EABI.  There's also a potential
> disaster in this area of the exploding cross-product: the core
> architecture is just one dimension in the matrix.
>
>
> > Perhaps the thing to do would be
> > to redefine the -A/--architecture option, which is only used for the
> > Intel i960.  -A currently affects library search order, which we would
> > not want for the new option.    However, I doubt that anybody uses the
> > i960 any more, and even if they do, they probably don't use the -A
> > option.
>
>
> I'd really like to be able to just pass -march through from the
> compiler.  Anything solution that needs any remapping beyond a common
> prefix substitution in a gcc spec file is just a disaster waiting to
> happen.

I've been working on a new patch, but now I come to think about it I'm 
unsure what the conclusion of this discussion was, so I may be just 
heading towards a dead-end. I think my confusion arises from there being 
two different things being discussed here: the behaviour of the linker 
(which relocations do what), and the representation of the architecture 
in the input and output files. As far as I can tell, the ARM EABI build 
attributes seem to be primarily concerned with the latter, and not so 
useful for the former. (And besides which, they aren't implemented yet, 
and I'm probably not the best person to do that.)

It seems to be quite easy to alter the behaviour of -A/--architecture to 
do the same as the linker script OUTPUT_ARCH, then use that information 
from the output bfd to control the linker's interpretation of 
R_ARM_THM_CALL. (It also suffices to control the behaviour of 
R_ARM_V4BX, by seeing if the current arch is armv4. Previous patch here:

  http://sourceware.org/ml/binutils/2005-01/msg00479.html )

But OUTPUT_ARCH also affects the output file, which isn't necessarily 
what we want if we're only trying to affect linker behaviour (and 
indeed, the build attributes are probably better for that).

So the choices as I see it are as follows:

  (1) Add a seperate "-march=xyz -> --foobar=xyz" style passthrough.
      This unfortunately gives ld and bfd a new and different concept of
      what an architecture is.

  (2) Use existing OUTPUT_ARCH machinery with a redefined --architecture
      option, and:
    (a) Don't use any automatic architecture passthrough from gcc, or
    (b) Extend bfd machine table with all the architectures gcc knows
        about, to enable .

  (3) Forget this for now, and use my original SymbianOS-specific patch.

I'm inclined towards 2a or 3. (e.g. for 2a, use explicit 
-Wl,--architecture,xyz when necessary). Comments?

Julian