[BUG?] GCC 4.5.2 produces deprecated ARM relocation

[BUG?] GCC 4.5.2 produces deprecated ARM relocation

[Ben Gamari]

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 
00000008 R_ARM_PLT32       hi

Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation

[Richard Earnshaw]

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.

R.

Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation

[Ben Gamari]

On Fri, 14 Oct 2011 18:38:26 +0100, Richard Earnshaw <rearnsha@arm.com> 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

[Richard Earnshaw]

On 14/10/11 19:31, Ben Gamari wrote:
> On Fri, 14 Oct 2011 18:38:26 +0100, Richard Earnshaw <rearnsha@arm.com> 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.

You need to take that up with the binutils folks, they don't generally
hang out on this list.

R.

Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation

[Ben Gamari]

On Mon, 24 Oct 2011 16:04:02 +0100, Nick Clifton <nickc@redhat.com> 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