Re: Which patch added R_ARM_GOTOFF32 support?
On Thu, 2006-06-29 at 03:47, Daniel Jacobowitz wrote: On Wed, Jun 28, 2006 at 03:54:29PM -0600, Shaun Jackman wrote: On 6/28/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote: I'm not terribly familiar with the GCC source tree. I scanned config/arm/arm.c and its SVN log for changes that might affect GOTOFF32, but came up empty. Do you know where the decision of GOT or GOTOFF would be handled? Sorry, it was written quite a while ago. I don't know. Do you know who added this feature? What is you, or perhaps Nick Clifton or Richard Earnshaw? If I could find the person and the file that added this feature, I could probably track down the patch in svn and modify it for XIP. It was probably me. But why can't you do this yourself? Look at the assembly. See what the output string is. Search for it in config/arm/. Use svn blame, as already suggested. No, it was PhilB, but it must have been two or three years ago now. R.
Re: Which patch added R_ARM_GOTOFF32 support?
On 6/29/06, Richard Earnshaw [EMAIL PROTECTED] wrote: No, it was PhilB, but it must have been two or three years ago now. Thanks, Richard. I suspect svn r71881 is responsible. I'll start testing and hopefully put a patch together. I would suspect r49871, but this patch is in 4.0.3, which doesn't emit GOTOFF. Cheers, Shaun r49871 2002-02-19 Philip Blundell [EMAIL PROTECTED] * config/arm/arm.c (arm_encode_call_attribute): Operate on any decl, not just FUNCTION_DECL. (legitimize_pic_address): Handle local SYMBOL_REF like LABEL_REF. (arm_assemble_integer): Likewise. * config/arm/arm.h (ARM_ENCODE_CALL_TYPE): Allow any decl to be marked local. r71881 2003-09-28 Philip Blundell [EMAIL PROTECTED] * config/arm/arm.c (legitimize_pic_address): Check SYMBOL_REF_LOCAL_P, not ENCODED_SHORT_CALL_ATTR_P. (arm_assemble_integer): Likewise.
Which patch added R_ARM_GOTOFF32 support?
Hello Richard, Dan, I'm trying to track down which part of the GCC source tree makes the decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation. A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a reference to a static function. I thought there was a good chance one of you two might have added this feature. If you're familiar with the the patch, would you please point me to the relevant ChangeLog entry? I'm hoping to add an exception for execute in place (XIP) code (-fPIC -msingle-pic-base) to use R_ARM_GOT32 instead of R_ARM_GOTOFF32. Many thanks, Shaun See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28194
Re: Which patch added R_ARM_GOTOFF32 support?
Shaun Jackman writes: Hello Richard, Dan, I'm trying to track down which part of the GCC source tree makes the decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation. A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a reference to a static function. I thought there was a good chance one of you two might have added this feature. If you're familiar with the the patch, would you please point me to the relevant ChangeLog entry? I'm hoping to add an exception for execute in place (XIP) code (-fPIC -msingle-pic-base) to use R_ARM_GOT32 instead of R_ARM_GOTOFF32. Many thanks, Shaun See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28194 Use svn blame Andrew.
Re: Which patch added R_ARM_GOTOFF32 support?
On Wed, Jun 28, 2006 at 11:20:00AM -0600, Shaun Jackman wrote: Hello Richard, Dan, I'm trying to track down which part of the GCC source tree makes the decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation. A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a reference to a static function. I thought there was a good chance one of you two might have added this feature. If you're familiar with the the patch, would you please point me to the relevant ChangeLog entry? I'm hoping to add an exception for execute in place (XIP) code (-fPIC -msingle-pic-base) to use R_ARM_GOT32 instead of R_ARM_GOTOFF32. GOTOFF support has been there for a long while. Only use of it for static functions is recent. It should be easy to find. But this is not at all the only problem. GCC's PIC model assumes a fixed displacement between segments. We've implemented something similar to what you need for VxWorks. A couple of other places had to be changed. I don't remember if the VxWorks gcc port was submitted, or just the binutils bits. -- Daniel Jacobowitz CodeSourcery
Re: Which patch added R_ARM_GOTOFF32 support?
On 6/28/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: GOTOFF support has been there for a long while. Only use of it for static functions is recent. It should be easy to find. But this is not at all the only problem. GCC's PIC model assumes a fixed displacement between segments. Even if a fixed displacement is a basic assumption, it doesn't seem to affect the ARM PIC/XIP code drastically, except for this specific case of a static callback function. Everything else seems to `just work'. A simple Hello, world! application linked statically against newlib and using stdio (which is fairly non-trivial) works, for example. I'm not terribly familiar with the GCC source tree. I scanned config/arm/arm.c and its SVN log for changes that might affect GOTOFF32, but came up empty. Do you know where the decision of GOT or GOTOFF would be handled? We've implemented something similar to what you need for VxWorks. A couple of other places had to be changed. I don't remember if the VxWorks gcc port was submitted, or just the binutils bits. Any chance of this work making it into GCC? Cheers, Shaun
Re: Which patch added R_ARM_GOTOFF32 support?
On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote: I'm not terribly familiar with the GCC source tree. I scanned config/arm/arm.c and its SVN log for changes that might affect GOTOFF32, but came up empty. Do you know where the decision of GOT or GOTOFF would be handled? Sorry, it was written quite a while ago. I don't know. We've implemented something similar to what you need for VxWorks. A couple of other places had to be changed. I don't remember if the VxWorks gcc port was submitted, or just the binutils bits. Any chance of this work making it into GCC? Yes - but we haven't had time to submit it. -- Daniel Jacobowitz CodeSourcery
Re: Which patch added R_ARM_GOTOFF32 support?
On 6/28/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote: I'm not terribly familiar with the GCC source tree. I scanned config/arm/arm.c and its SVN log for changes that might affect GOTOFF32, but came up empty. Do you know where the decision of GOT or GOTOFF would be handled? Sorry, it was written quite a while ago. I don't know. Do you know who added this feature? What is you, or perhaps Nick Clifton or Richard Earnshaw? If I could find the person and the file that added this feature, I could probably track down the patch in svn and modify it for XIP. Cheers, Shaun
Re: Which patch added R_ARM_GOTOFF32 support?
On Wed, Jun 28, 2006 at 03:54:29PM -0600, Shaun Jackman wrote: On 6/28/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote: I'm not terribly familiar with the GCC source tree. I scanned config/arm/arm.c and its SVN log for changes that might affect GOTOFF32, but came up empty. Do you know where the decision of GOT or GOTOFF would be handled? Sorry, it was written quite a while ago. I don't know. Do you know who added this feature? What is you, or perhaps Nick Clifton or Richard Earnshaw? If I could find the person and the file that added this feature, I could probably track down the patch in svn and modify it for XIP. It was probably me. But why can't you do this yourself? Look at the assembly. See what the output string is. Search for it in config/arm/. Use svn blame, as already suggested. -- Daniel Jacobowitz CodeSourcery
