* Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation
[not found] ` <4EA57E62.8020802@redhat.com>
@ 2011-10-25 14:46 ` Ben Gamari
0 siblings, 0 replies; 5+ messages in thread
From: Ben Gamari @ 2011-10-25 14:46 UTC (permalink / raw)
To: gcc; +Cc: Nick Clifton, Richard Earnshaw
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [BUG?] GCC 4.5.2 produces deprecated ARM relocation
@ 2011-10-14 17:38 Ben Gamari
2011-10-14 20:39 ` Richard Earnshaw
0 siblings, 1 reply; 5+ messages in thread
From: Ben Gamari @ 2011-10-14 17:38 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation
2011-10-14 17:38 Ben Gamari
@ 2011-10-14 20:39 ` Richard Earnshaw
2011-10-14 22:45 ` Ben Gamari
0 siblings, 1 reply; 5+ messages in thread
From: Richard Earnshaw @ 2011-10-14 20:39 UTC (permalink / raw)
To: Ben Gamari; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation
2011-10-14 20:39 ` Richard Earnshaw
@ 2011-10-14 22:45 ` Ben Gamari
2011-10-19 17:37 ` Richard Earnshaw
0 siblings, 1 reply; 5+ messages in thread
From: Ben Gamari @ 2011-10-14 22:45 UTC (permalink / raw)
To: Richard Earnshaw; +Cc: gcc
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation
2011-10-14 22:45 ` Ben Gamari
@ 2011-10-19 17:37 ` Richard Earnshaw
0 siblings, 0 replies; 5+ messages in thread
From: Richard Earnshaw @ 2011-10-19 17:37 UTC (permalink / raw)
To: Ben Gamari; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-10-25 13:50 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <87lisglw3i.fsf@gmail.com>
[not found] ` <4EA57E62.8020802@redhat.com>
2011-10-25 14:46 ` [BUG?] GCC 4.5.2 produces deprecated ARM relocation Ben Gamari
2011-10-14 17:38 Ben Gamari
2011-10-14 20:39 ` Richard Earnshaw
2011-10-14 22:45 ` Ben Gamari
2011-10-19 17:37 ` 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).