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

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Wed, 2005-03-16 at 16:39, Ian Lance Taylor wrote:

> OUTPUT_ARCH lets you specify an architecture.  For ARM, this will be
> one of the entries found in arch_info_struct in bfd/cpu-arm.c.  Of
> course that list can be adjusted.
> 

The current attributes proposal for the ABI lists 27 separate
attributes, giving rise to a theoretical 10^14 possible variants.  In
practice the number of realistic variants is much smaller than this, but
it's still much larger than can be listed explicitly in an arch_info
struct.

> I think the ELF header issue is irrelevant here.  That is a matter of
> how the architecture is represented in the output file.  It's
> obviously convenient to represent the architecture correctly in the
> output file so that it can be recognized by something reading the
> file, but that is not a requirement, and the information does not have
> to be in the ELF header.

The architecture is just one factor here.  Maybe the most important one,
but still just one of many.

> 
> > > 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.
> 
> The linker already has a -m option, used to specify the emulation to
> use, so -march itself would not work.  But I wouldn't be opposed to
> adding an option which just set the machine name.  I would have to be
> convinced about adding something which bypassed the existing BFD
> architecture/machine machinery.

A trivial mapping of -march=xxx to -foobar=xxx is not a problem.  It's
mapping xxx to yyy that must be avoided.  We used to try to do that in
the assembler and it wasn't maintainable.

R.