[BUG?] GCC 4.5.2 produces deprecated ARM relocation
I was recently trying to test GCC's behavior in producing various types of ARM relocations. In particular, I was trying to produce an R_ARM_JUMP24 relocation, which requires veneer. It was suggested that the code most likely to produce this relocation would involve some sort of tail recursion. I wrote up a small test[1] involving interworking and tail recursion to see what the produced object might look like. To my surprise, I found that the compiler instead[2] produced the deprecated R_ARM_PLT32 relocation. Considering the deprecated state of this relocation type, should this be considered a bug? Being a linker implementer, I for one would greatly appreciate it if GCC tried to only use non-deprecated relocation types. I apologize if this has already been fixed upstream. Cheers, - Ben [1] https://github.com/bgamari/arm-interworking-test [2] $ make cc -marm -fPIC -c -o main.o main.c cc -mthumb -fPIC -c -o thumb.o thumb.c gcc main.o thumb.o -o test.o $ objdump -r main.o main.o: file format elf32-littlearm RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0008 R_ARM_PLT32 hi
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
Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation
On Fri, 14 Oct 2011 18:38:26 +0100, Richard Earnshaw wrote: > On 14/10/11 17:40, Ben Gamari wrote: > > I was recently trying to test GCC's behavior in producing various types > > of ARM relocations. In particular, I was trying to produce an > > R_ARM_JUMP24 relocation, which requires veneer. It was suggested that > > the code most likely to produce this relocation would involve some sort > > of tail recursion. I wrote up a small test[1] involving interworking and > > tail recursion to see what the produced object might look like. To my > > surprise, I found that the compiler instead[2] produced the deprecated > > R_ARM_PLT32 relocation. Considering the deprecated state of this > > relocation type, should this be considered a bug? Being a linker > > implementer, I for one would greatly appreciate it if GCC tried to only > > use non-deprecated relocation types. I apologize if this has already > > been fixed upstream. > > > > The compiler doesn't produce relocations, but the assembler does. You > need to make sure your binutils is up-to-date. > Fair enough. I suppose that makes more sense. $ as -v GNU assembler version 2.21.0 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.21.0.20110327 Seems that this is the latest stable release. Cheers, - Ben
Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation
On Mon, 24 Oct 2011 16:04:02 +0100, Nick Clifton wrote: > Hi Ben, > > > To my > > surprise, I found that the compiler instead[2] produced the deprecated > > R_ARM_PLT32 relocation. Considering the deprecated state of this > > relocation type, should this be considered a bug? > > Yes... > > > Being a linker > > implementer, I for one would greatly appreciate it if GCC tried to only > > use non-deprecated relocation types. > > And so you will need to repost this bug report to the gcc bug mailing > list, since it is gcc's fault... > > What is happening is that GCC is producing this assembler output for the > call to hi(): > > bl hi(PLT) > > The presence of the "(PLT)" instructs GAS to produce the deprecated > ARM_PLT32 reloc. (See the ARM specific portion of the GAS documentation > for a mention of this). > > GCC is adding this suffix because the -fPIC flag enables NEED_PLT_RELOC > (see gcc/config/arm/elf.h). Why elf.h is doing this I am not sure - > backwards compatibility maybe ? Anyway it is GCC that needs fixing, not > GAS. > > Cheers >Nick
Re: gcc- 4.6.0 20100416 rtmutex.c:1138:1: internal compiler error
On Sun, 18 Apr 2010 21:19:19 -0700, Justin Mattock wrote: > so far I've compiled most of the system > (glibc,Xserver,etc..) > and not really anything has crashed and burned > except for the kernel: > You are using a pre-release compiler. It should be no surprise that it chokes on the kernel. You should do as the compiler said and report this to the gcc folks. - Ben
