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


Richard Earnshaw wrote:
On Wed, 2005-03-16 at 17:33, Ian Lance Taylor wrote:

Richard Earnshaw <rearnsha@gcc.gnu.org> writes:


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 guess I misunderstood the issue. I didn't realize that it was necessary to support a set of different attributes. I guess I don't understand why -march was brought up---march in gcc doesn't take a set of attributes.


-march was brought up because *in this particular case* it's the attribute that we are interested in: does the target architecture have the blx instruction? So it's true that *in this particular case* we could solve the problem in the info_arch vector: but we can't solve the general problem that way -- it requires more a complex solution.


Of course a set of attributes could be done in BFD by using the
machine number as a bitfield, but that is probably not the way to go.


You'd need something like 68 bits to fully describe the 27 attributes.

Implementing the whole of the build attributes machinery is going to be a lot of work. Richard, do you have a suggestion for a short-term plan for fixing the problem in hand which would be acceptible for you?


After experimenting with the OUTPUT_ARCH machinery, I've decided it probably isn't the right way of solving this (the treatment of the R_ARM_THM_CALL relocation at link-time). There are just too many fiddly corners involved - e.g. bfd_arm_merge_machines will happily override the OUTPUT_ARCH set in a linker script (or from the command-line, after patching).

Cheers,

Julian


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