This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]