xtensa-fsf-ld: dangerous relocation: call8: call target out of range

xtensa-fsf-ld: dangerous relocation: call8: call target out of range

[Max Filippov]

Hello.

I'm trying to build linux kernel for FSF xtensa core using binutils-2.22.
In the final linking step I get the following error:

+ /home/dumb/ws/tensilica/tools/xtensa-toolchain-build/build-xtensa-fsf-elf/root/bin/xtensa-fsf-elf-ld
--build-id -o .tmp_vmlinux2 -T
/home/dumb/ws/tensilica/linux/linux-build/fsf/defconfig/arch/xtensa/kernel/vmlinux.lds
arch/xtensa/kernel/head.o init/built-in.o --start-group usr/built-in.o
arch/xtensa/kernel/built-in.o arch/xtensa/mm/built-in.o
arch/xtensa/platforms/iss/built-in.o kernel/built-in.o mm/built-in.o
fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o
block/built-in.o lib/lib.a arch/xtensa/lib/lib.a
/home/dumb/ws/tensilica/tools/xtensa-toolchain-build/build-xtensa-fsf-elf/root/lib/gcc/xtensa-fsf-elf/4.6.3/libgcc.a
lib/built-in.o arch/xtensa/lib/built-in.o
/home/dumb/ws/tensilica/tools/xtensa-toolchain-build/build-xtensa-fsf-elf/root/lib/gcc/xtensa-fsf-elf/4.6.3/libgcc.a
drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o
--end-group .tmp_kallsyms1.o
net/built-in.o: In function `fib_net_init':
fib_frontend.c:(.init.text+0x1553): dangerous relocation: call8: call
target out of range: (.text+0x3eb38)

If I add --no-relax ld option to this link step everything works fine.

Referenced portion of the object file (net/built-in.o) looks like this:

    1550:       180000          l32r    a8, fffc1550
<unregister_net_sysctl_table+0xfff6eb90>
                        1550: R_XTENSA_SLOT0_OP .init.literal+0x5a0
                        1550: R_XTENSA_ASM_EXPAND       fib_trie_table
    1553:       0b8000          callx8  a8
    1556:       caa3            beqz.n  a10, 157d <fib_net_init+0x5d>

Can anybody suggest the way to debug/fix it?

-- 
Thanks.
-- Max

Re: xtensa-fsf-ld: dangerous relocation: call8: call target out of range

[Sterling Augustine]

On Mon, Jul 16, 2012 at 8:31 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>
> Sorry, missed CC to you.
>
> ---------- Forwarded message ----------
> From: Max Filippov <jcmvbkbc@gmail.com>
> Date: Mon, Jul 16, 2012 at 6:26 PM
> Subject: xtensa-fsf-ld: dangerous relocation: call8: call target out of range
> To: binutils@sourceware.org
> Cc: Marc Gauthier <marc@tensilica.com>
>
>
> Hello.
>
> I'm trying to build linux kernel for FSF xtensa core using binutils-2.22.
> In the final linking step I get the following error:
>
> + /home/dumb/ws/tensilica/tools/xtensa-toolchain-build/build-xtensa-fsf-elf/root/bin/xtensa-fsf-elf-ld
> --build-id -o .tmp_vmlinux2 -T
> /home/dumb/ws/tensilica/linux/linux-build/fsf/defconfig/arch/xtensa/kernel/vmlinux.lds
> arch/xtensa/kernel/head.o init/built-in.o --start-group usr/built-in.o
> arch/xtensa/kernel/built-in.o arch/xtensa/mm/built-in.o
> arch/xtensa/platforms/iss/built-in.o kernel/built-in.o mm/built-in.o
> fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o
> block/built-in.o lib/lib.a arch/xtensa/lib/lib.a
> /home/dumb/ws/tensilica/tools/xtensa-toolchain-build/build-xtensa-fsf-elf/root/lib/gcc/xtensa-fsf-elf/4.6.3/libgcc.a
> lib/built-in.o arch/xtensa/lib/built-in.o
> /home/dumb/ws/tensilica/tools/xtensa-toolchain-build/build-xtensa-fsf-elf/root/lib/gcc/xtensa-fsf-elf/4.6.3/libgcc.a
> drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o
> --end-group .tmp_kallsyms1.o
> net/built-in.o: In function `fib_net_init':
> fib_frontend.c:(.init.text+0x1553): dangerous relocation: call8: call
> target out of range: (.text+0x3eb38)
>
> If I add --no-relax ld option to this link step everything works fine.
>
> Referenced portion of the object file (net/built-in.o) looks like this:
>
>     1550:       180000          l32r    a8, fffc1550
> <unregister_net_sysctl_table+0xfff6eb90>
>                         1550: R_XTENSA_SLOT0_OP .init.literal+0x5a0
>                         1550: R_XTENSA_ASM_EXPAND       fib_trie_table
>     1553:       0b8000          callx8  a8
>     1556:       caa3            beqz.n  a10, 157d <fib_net_init+0x5d>
>
> Can anybody suggest the way to debug/fix it?


Looks like a linker bug to me. Quite likely the relaxer is
mis-estimating the distance to the call target, and converting the
l32r-callx8 sequence to a single call8 which can't reach. In the short
tem, --no-relax-ld is your only option. Your code will be slightly
larger and slightly slower, but it shouldn't be a dealbreaker.

In the longer term, someone at Tensilica will need to submit a patch,
so full repro instructions would be very good here. I think Tensilica
might maintain some private patches, but I don't know if they have
anything addresses this one. Marc?

Sterling

Re: xtensa-fsf-ld: dangerous relocation: call8: call target out of range

[Max Filippov]

On Mon, Jul 16, 2012 at 10:51 PM, Sterling Augustine
<augustine.sterling@gmail.com> wrote:
> On Mon, Jul 16, 2012 at 8:31 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>>
>> Sorry, missed CC to you.
>>
>> ---------- Forwarded message ----------
>> From: Max Filippov <jcmvbkbc@gmail.com>
>> Date: Mon, Jul 16, 2012 at 6:26 PM
>> Subject: xtensa-fsf-ld: dangerous relocation: call8: call target out of range
>> To: binutils@sourceware.org
>> Cc: Marc Gauthier <marc@tensilica.com>
>>
>>
>> Hello.
>>
>> I'm trying to build linux kernel for FSF xtensa core using binutils-2.22.
>> In the final linking step I get the following error:
>>
>> + /home/dumb/ws/tensilica/tools/xtensa-toolchain-build/build-xtensa-fsf-elf/root/bin/xtensa-fsf-elf-ld
>> --build-id -o .tmp_vmlinux2 -T
>> /home/dumb/ws/tensilica/linux/linux-build/fsf/defconfig/arch/xtensa/kernel/vmlinux.lds
>> arch/xtensa/kernel/head.o init/built-in.o --start-group usr/built-in.o
>> arch/xtensa/kernel/built-in.o arch/xtensa/mm/built-in.o
>> arch/xtensa/platforms/iss/built-in.o kernel/built-in.o mm/built-in.o
>> fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o
>> block/built-in.o lib/lib.a arch/xtensa/lib/lib.a
>> /home/dumb/ws/tensilica/tools/xtensa-toolchain-build/build-xtensa-fsf-elf/root/lib/gcc/xtensa-fsf-elf/4.6.3/libgcc.a
>> lib/built-in.o arch/xtensa/lib/built-in.o
>> /home/dumb/ws/tensilica/tools/xtensa-toolchain-build/build-xtensa-fsf-elf/root/lib/gcc/xtensa-fsf-elf/4.6.3/libgcc.a
>> drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o
>> --end-group .tmp_kallsyms1.o
>> net/built-in.o: In function `fib_net_init':
>> fib_frontend.c:(.init.text+0x1553): dangerous relocation: call8: call
>> target out of range: (.text+0x3eb38)
>>
>> If I add --no-relax ld option to this link step everything works fine.
>>
>> Referenced portion of the object file (net/built-in.o) looks like this:
>>
>>     1550:       180000          l32r    a8, fffc1550
>> <unregister_net_sysctl_table+0xfff6eb90>
>>                         1550: R_XTENSA_SLOT0_OP .init.literal+0x5a0
>>                         1550: R_XTENSA_ASM_EXPAND       fib_trie_table
>>     1553:       0b8000          callx8  a8
>>     1556:       caa3            beqz.n  a10, 157d <fib_net_init+0x5d>
>>
>> Can anybody suggest the way to debug/fix it?
>
> Looks like a linker bug to me. Quite likely the relaxer is
> mis-estimating the distance to the call target, and converting the
> l32r-callx8 sequence to a single call8 which can't reach. In the short
> tem, --no-relax-ld is your only option. Your code will be slightly
> larger and slightly slower, but it shouldn't be a dealbreaker.

Thanks for the answer.

> In the longer term, someone at Tensilica will need to submit a patch,
> so full repro instructions would be very good here. I think Tensilica

I have a tagged linux tree and mostly scripted build procedure which I
can share.

> might maintain some private patches, but I don't know if they have
> anything addresses this one. Marc?
>
> Sterling

-- 
Thanks.
-- Max

Re: xtensa-fsf-ld: dangerous relocation: call8: call target out of range

[nick clifton]

Hi Max,
> net/built-in.o: In function `fib_net_init':
> fib_frontend.c:(.init.text+0x1553): dangerous relocation: call8: call
> target out of range: (.text+0x3eb38)

> If I add --no-relax ld option to this link step everything works fine.
>
> Referenced portion of the object file (net/built-in.o) looks like this:
>
>      1550:       180000          l32r    a8, fffc1550
> <unregister_net_sysctl_table+0xfff6eb90>
>                          1550: R_XTENSA_SLOT0_OP .init.literal+0x5a0
>                          1550: R_XTENSA_ASM_EXPAND       fib_trie_table
>      1553:       0b8000          callx8  a8
>      1556:       caa3            beqz.n  a10, 157d <fib_net_init+0x5d>
>
> Can anybody suggest the way to debug/fix it?

Take a look at bfd/elf32-xtensa.c.  In particular the relax_section() 
function. (Compiling with "#define DEBUG 1" might help).

It looks like linker relaxation on the xtensa is quite extensive 
however, so you may have some trouble narrowing down the exact bug.  You 
could try contacting Sterling Augustine, the Xtensa maintainer for more 
help.  You might also wish to file a binutils bug report on the problem 
(at http://sourceware.org/bugzilla/), althpugh if you do this it would 
be really useful if you can include a small test case to reproduce the 
problem.

Cheers
   Nick

Re: xtensa-fsf-ld: dangerous relocation: call8: call target out of range

[Max Filippov]

On Tue, Jul 17, 2012 at 12:33 PM, nick clifton <nickc@redhat.com> wrote:
> Hi Max,
>
>> net/built-in.o: In function `fib_net_init':
>> fib_frontend.c:(.init.text+0x1553): dangerous relocation: call8: call
>> target out of range: (.text+0x3eb38)
>
>> If I add --no-relax ld option to this link step everything works fine.
>>
>> Can anybody suggest the way to debug/fix it?
>
>
> Take a look at bfd/elf32-xtensa.c.  In particular the relax_section()
> function. (Compiling with "#define DEBUG 1" might help).
>
> It looks like linker relaxation on the xtensa is quite extensive however, so
> you may have some trouble narrowing down the exact bug.  You could try
> contacting Sterling Augustine, the Xtensa maintainer for more help.  You
> might also wish to file a binutils bug report on the problem (at
> http://sourceware.org/bugzilla/), althpugh if you do this it would be really
> useful if you can include a small test case to reproduce the problem.

Hi Nick,

thanks for your suggestion. I was trying to make a test case when I found that
I used FSF overlay from older (2.20.1) binutils. With clean
binutils/gcc toolchain
kernel build passes. This brings up the following questions:
- is it still worth to debug the issue with the recent binutils +
older FSF overlay?
  (seems like the answer is "yes", because relaxation logic does not
belong to overlay)
- how comes that FSF overlay has different features in different
binutils releases?

-- 
Thanks.
-- Max

Re: xtensa-fsf-ld: dangerous relocation: call8: call target out of range

[nick clifton]

Hi Max,

 > thanks for your suggestion. I was trying to make a test case when I
 > found that I used FSF overlay

Umm, what exactly do you mean by "overlay" ?

 > from older (2.20.1) binutils. With clean binutils/gcc toolchain
> kernel build passes.

Are you talking about the linker's ability to generate groups of 
sections that overlay each other ?

Cheers
   Nick

Re: xtensa-fsf-ld: dangerous relocation: call8: call target out of range

[Max Filippov]

On Wed, Jul 18, 2012 at 3:44 PM, nick clifton <nickc@redhat.com> wrote:
> Hi Max,
>
>
>> thanks for your suggestion. I was trying to make a test case when I
>> found that I used FSF overlay
>
> Umm, what exactly do you mean by "overlay" ?

That's how you configure binutils, gcc, gdb and linux for the specific
Tensilica processor. In short it's a number of *.h/*.c files generated
by Tensilica tools as a by-product of processor core instantiation.
They provide various processor-specific #defines and functions.

Stock binutils, gcc and gdb are configured with the so-called 'FSF'
overlay.

What's strange with it is that overlay corresponds to a specific
processor core configuration, it shouldn't change over time: if it
does, it should be another overlay, for another processor core.

And binutils/gcc and linux should be configured with one overlay,
which is now broken.

>> from older (2.20.1) binutils. With clean binutils/gcc toolchain
>>
>> kernel build passes.
>
> Are you talking about the linker's ability to generate groups of sections
> that overlay each other ?

-- 
Thanks.
-- Max

Re: xtensa-fsf-ld: dangerous relocation: call8: call target out of range

[nick clifton]

Hi Max

> This brings up the following questions:
> - is it still worth to debug the issue with the recent binutils +
> older FSF overlay?

Err, is that possible ?  I thought that the "FSF overlay" was the stock 
set of Tensilica specific *.c/*.h files distributed with a binutils 
release.  If so then if you are using a "recent binutils" then you 
surely would be using the "FSF overlay" that comes with these sources, 
not an older one, right ?


> (seems like the answer is "yes", because relaxation logic does not
>  belong to overlay)

Well the relaxation performed by the linker is xtensa specific, so maybe 
one or more of the overlay files do influence the behaviour of the 
relaxation process.  (Possibly via the presence or absence of a #define ?)


> - how comes that FSF overlay has different features in different
> - binutils releases?

I presume that this is because of bug fixing.


My current feeling is: If the problem is fixed in the current release, 
but broken in an older release, then do not worry about fixing the older 
release.  Add a requirement to the kernel build to use binutils of at 
least the current version and go on to fix the next bug. :-)

Cheers
   Nick

Re: xtensa-fsf-ld: dangerous relocation: call8: call target out of range

[Max Filippov]

On Wed, Jul 18, 2012 at 4:40 PM, nick clifton <nickc@redhat.com> wrote:
> Hi Max
>
>> This brings up the following questions:
>> - is it still worth to debug the issue with the recent binutils +
>> older FSF overlay?
>
> Err, is that possible ?  I thought that the "FSF overlay" was the stock set
> of Tensilica specific *.c/*.h files distributed with a binutils release.  If
> so then if you are using a "recent binutils" then you surely would be using
> the "FSF overlay" that comes with these sources, not an older one, right ?

Once upon a time I made myself an "FSF overlay" for binutils/gcc/gdb/linux
out of then current versions thereof. That overlay had consistent #defines.
Now stock binutils definitions conflict with stock linux definitions, it makes
no sense to build it that way.

>> (seems like the answer is "yes", because relaxation logic does not
>>  belong to overlay)
>
> Well the relaxation performed by the linker is xtensa specific, so maybe one
> or more of the overlay files do influence the behaviour of the relaxation
> process.  (Possibly via the presence or absence of a #define ?)

That's a question for binutils + xtensa expert, which I'm not (yet).
Sterling? Marc?

>> - how comes that FSF overlay has different features in different
>> - binutils releases?
>
> I presume that this is because of bug fixing.

I've no idea. That's why I Cc: Bob Wilson, who's contributed FSF overlay
to binutils, maybe he can shed some light on what was intended with
the change.

> My current feeling is: If the problem is fixed in the current release, but
> broken in an older release, then do not worry about fixing the older
> release.  Add a requirement to the kernel build to use binutils of at least
> the current version and go on to fix the next bug. :-)

-- 
Thanks.
-- Max

Re: xtensa-fsf-ld: dangerous relocation: call8: call target out of range

[Bob Wilson]

On Jul 18, 2012, at 7:09 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> 
>>> - how comes that FSF overlay has different features in different
>>> - binutils releases?
>> 
>> I presume that this is because of bug fixing.
> 
> I've no idea. That's why I Cc: Bob Wilson, who's contributed FSF overlay
> to binutils, maybe he can shed some light on what was intended with
> the change.

Sorry, I can't shed any light on this.  I haven't been involved with Xtensa or binutils for several years.  When I last looked at it, Tensilica's overlay files had the same features, possibly with different settings, as the trunk binutils sources at that time.

Re: xtensa-fsf-ld: dangerous relocation: call8: call target out of range

[Sterling Augustine]

On Wed, Jul 18, 2012 at 7:09 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> On Wed, Jul 18, 2012 at 4:40 PM, nick clifton <nickc@redhat.com> wrote:
>> Hi Max
>>
>>> This brings up the following questions:
>>> - is it still worth to debug the issue with the recent binutils +
>>> older FSF overlay?
>>
>> Err, is that possible ?  I thought that the "FSF overlay" was the stock set
>> of Tensilica specific *.c/*.h files distributed with a binutils release.  If
>> so then if you are using a "recent binutils" then you surely would be using
>> the "FSF overlay" that comes with these sources, not an older one, right ?
>
> Once upon a time I made myself an "FSF overlay" for binutils/gcc/gdb/linux
> out of then current versions thereof. That overlay had consistent #defines.
> Now stock binutils definitions conflict with stock linux definitions, it makes
> no sense to build it that way.
>
>>> (seems like the answer is "yes", because relaxation logic does not
>>>  belong to overlay)
>>
>> Well the relaxation performed by the linker is xtensa specific, so maybe one
>> or more of the overlay files do influence the behaviour of the relaxation
>> process.  (Possibly via the presence or absence of a #define ?)
>
> That's a question for binutils + xtensa expert, which I'm not (yet).
> Sterling? Marc?
>
>>> - how comes that FSF overlay has different features in different
>>> - binutils releases?
>>
>> I presume that this is because of bug fixing.
>
> I've no idea. That's why I Cc: Bob Wilson, who's contributed FSF overlay
> to binutils, maybe he can shed some light on what was intended with
> the change.
>
>> My current feeling is: If the problem is fixed in the current release, but
>> broken in an older release, then do not worry about fixing the older
>> release.  Add a requirement to the kernel build to use binutils of at least
>> the current version and go on to fix the next bug. :-)

Someone from Tensilica really needs to jump in here--they should know
the status of the various overlays. Marc? Piet? Dror?

As to why an overlay could affect relaxation, that would have to do
with the instructions available in the processor, and how they might
be issued together. The relaxation mechanism itself wouldn't be
affected, but the instructions it has to work with would be. Also, the
Linux build exercises relocatable links in ways that are a bit
unusual.

Sterling