This is the mail archive of the binutils@sourceware.org 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]

Handling R_ARM_JUMP24 with inter-working


Recently I've been taking a foray into the ARM ABI to port the Glasgow
Haskell Compiler's internal linker to ARM. One question I've run into is
how to handle the case of interworking with R_ARM_JUMP24. This
particular relocation could be generated often by GHC as a result of
tail call optimization.

According to the ELF for ARM specification, this case requires the
generation of veneer code to handle the instruction set switch. My
question is where can one reliably place this veneer such that it is
within the 2^11 window permitted by the relevant instructions. This is
made difficult considering the fact that in the general case .text
itself may be over 2^11 bytes long. It seems that the ELF for ARM
specification gives a format for veneer symbol naming in appendix B, but
compilers are not required to support this. How does one generally handle
placing these relocations?

Also, I have seen references[1] to an INTERWORK flag encoded somewhere in
the ELF, but I haven't been able to find any references to this in the
specification. Could someone point me in the right direction here?

It has been suggested that the compiler might include an 8 byte vacancy
for veneer after functions where this relocation might be necessary. I
have seen that GCC has an -mthumb-interwork option and while the
documentation does not directly say this is the option's effect, it is
suggestive. Can someone explain exactly what this option does?

Cheers,

- Ben


[1] http://gcc.gnu.org/ml/gcc/2004-03/msg00373.html


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