* [PATCH] Fix thumb calls via PLT on ARM/SymbianOS @ 2005-03-16 14:52 Julian Brown 2005-03-16 14:56 ` Richard Earnshaw 0 siblings, 1 reply; 18+ messages in thread From: Julian Brown @ 2005-03-16 14:52 UTC (permalink / raw) To: binutils; +Cc: julian [-- Attachment #1: Type: text/plain, Size: 645 bytes --] Hi, This patch fixes calls made from thumb mode via the PLT on SymbianOS. PLT entries are written in ARM mode, but previously they were being called in thumb mode, with their address incorrectly offset by -4 (PLT_THUMB_STUB_SIZE). Now, the target address has been corrected and the thumb BL instruction is rewritten as BLX to perform the mode switch before attempting to execute the PLT entry. (BLX is an armv5t instruction, but as SymbianOS is only targeted at armv5t+, this should always be OK.) The hardwired "4" for the thumb stub size on non-SymbianOS targets has also been rewritten as PLT_THUMB_STUB_SIZE. OK to apply? Julian [-- Attachment #2: patch-3 --] [-- Type: text/plain, Size: 1191 bytes --] Index: bfd/elf32-arm.c =================================================================== RCS file: /cvs/src/src/bfd/elf32-arm.c,v retrieving revision 1.22 diff -c -p -r1.22 elf32-arm.c *** bfd/elf32-arm.c 11 Feb 2005 16:41:09 -0000 1.22 --- bfd/elf32-arm.c 16 Mar 2005 12:38:29 -0000 *************** elf32_arm_final_link_relocate (reloc_how *** 2692,2699 **** value = (splt->output_section->vma + splt->output_offset + h->plt.offset); ! /* Target the Thumb stub before the ARM PLT entry. */ ! value -= 4; } relocation = value + signed_addend; --- 2692,2708 ---- value = (splt->output_section->vma + splt->output_offset + h->plt.offset); ! if (globals->symbian_p) ! { ! /* On SymbianOS, we are guaranteed to be using at least ARMv5t. ! Convert the BL to a BLX instruction to call the ARM-mode PLT ! entry. */ ! if ((lower_insn & (0x3 << 11)) == 0x3 << 11) ! lower_insn = (lower_insn & ~(0x3 << 11)) | 0x1 << 11; ! } ! else ! /* Target the Thumb stub before the ARM PLT entry. */ ! value -= PLT_THUMB_STUB_SIZE; } relocation = value + signed_addend; ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-16 14:52 [PATCH] Fix thumb calls via PLT on ARM/SymbianOS Julian Brown @ 2005-03-16 14:56 ` Richard Earnshaw 2005-03-16 15:27 ` Daniel Jacobowitz 0 siblings, 1 reply; 18+ messages in thread From: Richard Earnshaw @ 2005-03-16 14:56 UTC (permalink / raw) To: Julian Brown; +Cc: binutils On Wed, 2005-03-16 at 14:17, Julian Brown wrote: > Hi, > > This patch fixes calls made from thumb mode via the PLT on SymbianOS. > PLT entries are written in ARM mode, but previously they were being > called in thumb mode, with their address incorrectly offset by -4 > (PLT_THUMB_STUB_SIZE). > > Now, the target address has been corrected and the thumb BL instruction > is rewritten as BLX to perform the mode switch before attempting to > execute the PLT entry. (BLX is an armv5t instruction, but as SymbianOS > is only targeted at armv5t+, this should always be OK.) > > The hardwired "4" for the thumb stub size on non-SymbianOS targets has > also been rewritten as PLT_THUMB_STUB_SIZE. > > OK to apply? This sounds like a hack. I'd much rather a generic solution were found (and which permitted the blx optimization if available). R. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-16 14:56 ` Richard Earnshaw @ 2005-03-16 15:27 ` Daniel Jacobowitz 2005-03-16 16:10 ` Julian Brown 2005-03-16 16:16 ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS Richard Earnshaw 0 siblings, 2 replies; 18+ messages in thread From: Daniel Jacobowitz @ 2005-03-16 15:27 UTC (permalink / raw) To: Richard Earnshaw; +Cc: Julian Brown, binutils On Wed, Mar 16, 2005 at 02:23:12PM +0000, Richard Earnshaw wrote: > On Wed, 2005-03-16 at 14:17, Julian Brown wrote: > > Hi, > > > > This patch fixes calls made from thumb mode via the PLT on SymbianOS. > > PLT entries are written in ARM mode, but previously they were being > > called in thumb mode, with their address incorrectly offset by -4 > > (PLT_THUMB_STUB_SIZE). > > > > Now, the target address has been corrected and the thumb BL instruction > > is rewritten as BLX to perform the mode switch before attempting to > > execute the PLT entry. (BLX is an armv5t instruction, but as SymbianOS > > is only targeted at armv5t+, this should always be OK.) > > > > The hardwired "4" for the thumb stub size on non-SymbianOS targets has > > also been rewritten as PLT_THUMB_STUB_SIZE. > > > > OK to apply? > > This sounds like a hack. I'd much rather a generic solution were found > (and which permitted the blx optimization if available). The SymbianOS bits sound generally right to me. The fact that the -4 bias is currently included is just a bug; that's from the code to generate a Thumb header on PLT entries, which is already disabled for SymbianOS. OTOH, it may be missing some error checks - what if it's _not_ a BL? Could we reach here? Ideally, yes, I want to do this transformation on non-SymbianOS too. But, we don't have a clear indicator saying "yes it is save to generate blx" yet. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-16 15:27 ` Daniel Jacobowitz @ 2005-03-16 16:10 ` Julian Brown 2005-03-16 16:29 ` Richard Earnshaw 2005-03-16 16:42 ` Ian Lance Taylor 2005-03-16 16:16 ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS Richard Earnshaw 1 sibling, 2 replies; 18+ messages in thread From: Julian Brown @ 2005-03-16 16:10 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Richard Earnshaw, binutils, Julian Brown Daniel Jacobowitz wrote: > On Wed, Mar 16, 2005 at 02:23:12PM +0000, Richard Earnshaw wrote: > >>On Wed, 2005-03-16 at 14:17, Julian Brown wrote: >> >>>Hi, >>> >>>This patch fixes calls made from thumb mode via the PLT on SymbianOS. >>>PLT entries are written in ARM mode, but previously they were being >>>called in thumb mode, with their address incorrectly offset by -4 >>>(PLT_THUMB_STUB_SIZE). >>> >>>Now, the target address has been corrected and the thumb BL instruction >>>is rewritten as BLX to perform the mode switch before attempting to >>>execute the PLT entry. (BLX is an armv5t instruction, but as SymbianOS >>>is only targeted at armv5t+, this should always be OK.) >>> >>>The hardwired "4" for the thumb stub size on non-SymbianOS targets has >>>also been rewritten as PLT_THUMB_STUB_SIZE. >>> >>>OK to apply? >> >>This sounds like a hack. I'd much rather a generic solution were found >>(and which permitted the blx optimization if available). > > > The SymbianOS bits sound generally right to me. The fact that the -4 > bias is currently included is just a bug; that's from the code to > generate a Thumb header on PLT entries, which is already disabled > for SymbianOS. > > OTOH, it may be missing some error checks - what if it's _not_ a BL? > Could we reach here? I assumed not: this is an R_ARM_THM_PC22, alias R_ARM_THM_CALL relocation. Can that sensibly point at anything else? 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. Julian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-16 16:10 ` Julian Brown @ 2005-03-16 16:29 ` Richard Earnshaw 2005-03-16 16:34 ` Julian Brown 2005-03-16 16:42 ` Ian Lance Taylor 1 sibling, 1 reply; 18+ messages in thread From: Richard Earnshaw @ 2005-03-16 16:29 UTC (permalink / raw) To: Julian Brown; +Cc: Daniel Jacobowitz, binutils On Wed, 2005-03-16 at 14:49, Julian Brown wrote: > Daniel Jacobowitz wrote: > > On Wed, Mar 16, 2005 at 02:23:12PM +0000, Richard Earnshaw wrote: > > > >>On Wed, 2005-03-16 at 14:17, Julian Brown wrote: > >> > >>>Hi, > >>> > >>>This patch fixes calls made from thumb mode via the PLT on SymbianOS. > >>>PLT entries are written in ARM mode, but previously they were being > >>>called in thumb mode, with their address incorrectly offset by -4 > >>>(PLT_THUMB_STUB_SIZE). > >>> > >>>Now, the target address has been corrected and the thumb BL instruction > >>>is rewritten as BLX to perform the mode switch before attempting to > >>>execute the PLT entry. (BLX is an armv5t instruction, but as SymbianOS > >>>is only targeted at armv5t+, this should always be OK.) > >>> > >>>The hardwired "4" for the thumb stub size on non-SymbianOS targets has > >>>also been rewritten as PLT_THUMB_STUB_SIZE. > >>> > >>>OK to apply? > >> > >>This sounds like a hack. I'd much rather a generic solution were found > >>(and which permitted the blx optimization if available). > > > > > > The SymbianOS bits sound generally right to me. The fact that the -4 > > bias is currently included is just a bug; that's from the code to > > generate a Thumb header on PLT entries, which is already disabled > > for SymbianOS. > > > > OTOH, it may be missing some error checks - what if it's _not_ a BL? > > Could we reach here? > > I assumed not: this is an R_ARM_THM_PC22, alias R_ARM_THM_CALL > relocation. Can that sensibly point at anything else? > Ah! Yep, that can only apply to a thumb BL instruction. > 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. Yep, I think that would be a good idea. Ideally we'd want a linker command-line option as well, but a configuration option would be a good first step. R. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-16 16:29 ` Richard Earnshaw @ 2005-03-16 16:34 ` Julian Brown 0 siblings, 0 replies; 18+ messages in thread From: Julian Brown @ 2005-03-16 16:34 UTC (permalink / raw) To: Richard Earnshaw; +Cc: Daniel Jacobowitz, binutils, Julian Brown Richard Earnshaw wrote: > On Wed, 2005-03-16 at 14:49, Julian Brown wrote: > >>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. > > > Yep, I think that would be a good idea. Ideally we'd want a linker > command-line option as well, but a configuration option would be a good > first step. Sorry, cross-purposes: a linker command-line option was more like what I had in mind. I'll see what I can come up with. Julian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-16 16:10 ` Julian Brown 2005-03-16 16:29 ` Richard Earnshaw @ 2005-03-16 16:42 ` Ian Lance Taylor 2005-03-16 16:54 ` Richard Earnshaw 1 sibling, 1 reply; 18+ messages in thread From: Ian Lance Taylor @ 2005-03-16 16:42 UTC (permalink / raw) To: Julian Brown; +Cc: Daniel Jacobowitz, Richard Earnshaw, binutils 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. 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. Ian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-16 16:42 ` Ian Lance Taylor @ 2005-03-16 16:54 ` Richard Earnshaw 2005-03-16 17:16 ` Ian Lance Taylor 2005-03-17 20:58 ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) Julian Brown 0 siblings, 2 replies; 18+ messages in thread From: Richard Earnshaw @ 2005-03-16 16:54 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Julian Brown, Daniel Jacobowitz, binutils 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. R. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-16 16:54 ` Richard Earnshaw @ 2005-03-16 17:16 ` Ian Lance Taylor 2005-03-16 17:34 ` Richard Earnshaw 2005-03-17 20:58 ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) Julian Brown 1 sibling, 1 reply; 18+ messages in thread From: Ian Lance Taylor @ 2005-03-16 17:16 UTC (permalink / raw) To: Richard Earnshaw; +Cc: Julian Brown, Daniel Jacobowitz, binutils Richard Earnshaw <rearnsha@gcc.gnu.org> writes: > 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. 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. 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. > > 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. Ian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-16 17:16 ` Ian Lance Taylor @ 2005-03-16 17:34 ` Richard Earnshaw 2005-03-16 22:00 ` Ian Lance Taylor 0 siblings, 1 reply; 18+ messages in thread From: Richard Earnshaw @ 2005-03-16 17:34 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Julian Brown, Daniel Jacobowitz, binutils 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-16 17:34 ` Richard Earnshaw @ 2005-03-16 22:00 ` Ian Lance Taylor 2005-03-17 0:13 ` Richard Earnshaw 0 siblings, 1 reply; 18+ messages in thread From: Ian Lance Taylor @ 2005-03-16 22:00 UTC (permalink / raw) To: Richard Earnshaw; +Cc: Julian Brown, Daniel Jacobowitz, binutils 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. 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. The general usage in BFD architecture usage is to focus on existing processors, and sometimes to add nonexistent intermediate processors for convenience (e.g., bfd/cpu-sh.c). Ian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-16 22:00 ` Ian Lance Taylor @ 2005-03-17 0:13 ` Richard Earnshaw 2005-03-18 19:59 ` Julian Brown 0 siblings, 1 reply; 18+ messages in thread From: Richard Earnshaw @ 2005-03-17 0:13 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Julian Brown, Daniel Jacobowitz, binutils 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. R. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-17 0:13 ` Richard Earnshaw @ 2005-03-18 19:59 ` Julian Brown 0 siblings, 0 replies; 18+ messages in thread From: Julian Brown @ 2005-03-18 19:59 UTC (permalink / raw) To: Richard Earnshaw; +Cc: binutils, julian 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) 2005-03-16 16:54 ` Richard Earnshaw 2005-03-16 17:16 ` Ian Lance Taylor @ 2005-03-17 20:58 ` Julian Brown 2005-03-17 21:03 ` Question! NK 2005-03-17 21:25 ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) Paul Brook 1 sibling, 2 replies; 18+ messages in thread From: Julian Brown @ 2005-03-17 20:58 UTC (permalink / raw) To: Richard Earnshaw; +Cc: Ian Lance Taylor, Daniel Jacobowitz, binutils 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Question! 2005-03-17 20:58 ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) Julian Brown @ 2005-03-17 21:03 ` NK 2005-03-23 20:11 ` Question! Nick Clifton 2005-03-17 21:25 ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) Paul Brook 1 sibling, 1 reply; 18+ messages in thread From: NK @ 2005-03-17 21:03 UTC (permalink / raw) To: binutils Hello all, I have question regarding LD, I have modified the SEARCH_DIR path in the ld using --with-lib-path during configuration. I want ld to look into new path for libraries I have specified. Interestingly it is going into /usr/bin and accessing libc.so from there.. and because I have modified the SEARCH_DIR so it is not going into /lib and unable to find ld-linux.so.2, but going in /usr/lib; this is something I don't want. So my question is even if I have modified the SEARCH_DIR in ld why it is going into /usr/lib (path is not there)? Is there a way to prevent that... or it is hard coded somewhere in the code. I have all libc .so in path I have specified also, but not picking from there... Thanks a lot in advance. -nk ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Question! 2005-03-17 21:03 ` Question! NK @ 2005-03-23 20:11 ` Nick Clifton 0 siblings, 0 replies; 18+ messages in thread From: Nick Clifton @ 2005-03-23 20:11 UTC (permalink / raw) To: NK; +Cc: binutils Hi NK, > I have question regarding LD, I have modified the SEARCH_DIR path in > the ld using --with-lib-path during configuration. I want ld to look > into new path for libraries I have specified. > > Interestingly it is going into /usr/bin and accessing libc.so from > there.. and because I have modified the SEARCH_DIR so it is not going > into /lib and unable to find ld-linux.so.2, but going in /usr/lib; > this is something I don't want. > > So my question is even if I have modified the SEARCH_DIR in ld why it > is going into /usr/lib (path is not there)? Is there a way to prevent > that... or it is hard coded somewhere in the code. I have all libc .so > in path I have specified also, but not picking from there... You may well have encountered a bug in the linker. The --with-lib-path configure switch is supposed to control where the linker will look for libraries. If you can reproduce this problem using the latest sources in the binutils CVS repository then please submit a bug report, including a small working example of the problem, via the binutils bugzilla system at: http://sources.redhat.com/bugzilla/ Cheers Nick ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) 2005-03-17 20:58 ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) Julian Brown 2005-03-17 21:03 ` Question! NK @ 2005-03-17 21:25 ` Paul Brook 1 sibling, 0 replies; 18+ messages in thread From: Paul Brook @ 2005-03-17 21:25 UTC (permalink / raw) To: binutils Cc: Julian Brown, Richard Earnshaw, Ian Lance Taylor, Daniel Jacobowitz > (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? I think passing though the gcc -march= and -mcpu= options (you need both) would be a waste of effort. This should be mostly redundant once we implement build proper object build attributes. Paul ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS 2005-03-16 15:27 ` Daniel Jacobowitz 2005-03-16 16:10 ` Julian Brown @ 2005-03-16 16:16 ` Richard Earnshaw 1 sibling, 0 replies; 18+ messages in thread From: Richard Earnshaw @ 2005-03-16 16:16 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Julian Brown, binutils On Wed, 2005-03-16 at 14:42, Daniel Jacobowitz wrote: > On Wed, Mar 16, 2005 at 02:23:12PM +0000, Richard Earnshaw wrote: > > On Wed, 2005-03-16 at 14:17, Julian Brown wrote: > > > Hi, > > > > > > This patch fixes calls made from thumb mode via the PLT on SymbianOS. > > > PLT entries are written in ARM mode, but previously they were being > > > called in thumb mode, with their address incorrectly offset by -4 > > > (PLT_THUMB_STUB_SIZE). > > > > > > Now, the target address has been corrected and the thumb BL instruction > > > is rewritten as BLX to perform the mode switch before attempting to > > > execute the PLT entry. (BLX is an armv5t instruction, but as SymbianOS > > > is only targeted at armv5t+, this should always be OK.) > > > > > > The hardwired "4" for the thumb stub size on non-SymbianOS targets has > > > also been rewritten as PLT_THUMB_STUB_SIZE. > > > > > > OK to apply? > > > > This sounds like a hack. I'd much rather a generic solution were found > > (and which permitted the blx optimization if available). > > The SymbianOS bits sound generally right to me. The fact that the -4 > bias is currently included is just a bug; that's from the code to > generate a Thumb header on PLT entries, which is already disabled > for SymbianOS. > I'll have to look at that bit in further detail. > OTOH, it may be missing some error checks - what if it's _not_ a BL? > Could we reach here? > Possibly. Tail call? Doesn't happen in GCC, but another compiler might do it. > Ideally, yes, I want to do this transformation on non-SymbianOS too. > But, we don't have a clear indicator saying "yes it is save to generate > blx" yet. We shouldn't be testing SymbianOS here. We should be testing whether blx is available. If it is, then use the blx sequence; if not, then use a further trampoline that switches to ARM state and then jumps to the PLT. Other code in the initialization sequence can then mark that symbianos always has blx available. R. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2005-03-23 14:41 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-03-16 14:52 [PATCH] Fix thumb calls via PLT on ARM/SymbianOS Julian Brown 2005-03-16 14:56 ` Richard Earnshaw 2005-03-16 15:27 ` Daniel Jacobowitz 2005-03-16 16:10 ` Julian Brown 2005-03-16 16:29 ` Richard Earnshaw 2005-03-16 16:34 ` Julian Brown 2005-03-16 16:42 ` Ian Lance Taylor 2005-03-16 16:54 ` Richard Earnshaw 2005-03-16 17:16 ` Ian Lance Taylor 2005-03-16 17:34 ` Richard Earnshaw 2005-03-16 22:00 ` Ian Lance Taylor 2005-03-17 0:13 ` Richard Earnshaw 2005-03-18 19:59 ` Julian Brown 2005-03-17 20:58 ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) Julian Brown 2005-03-17 21:03 ` Question! NK 2005-03-23 20:11 ` Question! Nick Clifton 2005-03-17 21:25 ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) Paul Brook 2005-03-16 16:16 ` [PATCH] Fix thumb calls via PLT on ARM/SymbianOS Richard Earnshaw
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).