Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1458486 > unrolled thread

c6x linker issue on linux-next-20160808 + some linker table work

Back to article view | Back to linux.kernel

Contents

  c6x linker issue on linux-next-20160808 + some linker table work "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-09 10:20 +0200
    Re: c6x linker issue on linux-next-20160808 + some linker table work Guenter Roeck <linux@roeck-us.net> - 2016-08-09 15:40 +0200
      Re: c6x linker issue on linux-next-20160808 + some linker table work Mark Salter <msalter@redhat.com> - 2016-08-09 19:10 +0200
        Re: c6x linker issue on linux-next-20160808 + some linker table work Mark Salter <msalter@redhat.com> - 2016-08-09 20:50 +0200
        Re: c6x linker issue on linux-next-20160808 + some linker table work "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-09 20:50 +0200
          Re: c6x linker issue on linux-next-20160808 + some linker table work Mark Salter <msalter@redhat.com> - 2016-08-10 04:00 +0200
            Re: c6x linker issue on linux-next-20160808 + some linker table work Mark Salter <msalter@redhat.com> - 2016-08-10 05:10 +0200

#1458486 — c6x linker issue on linux-next-20160808 + some linker table work

Mark, Aurelien,

I've run into a linker (ld) issue caused by the linker table work I've
been working on [0]. I looked into this and for the life of me, I
cannot comprehend what the problem is, so was hoping you folks might
be able to chime in.

A snapshot you can use is available here:

https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160808-linker-table-v4

The commit that causes the issue is "firmware: port built-in section
to linker table":

https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20160808-linker-table-v4&id=2f4516be8c89b3ca008962798d44b54751e62844

its the first use of linker tables in the kernel, but I can't figure
out why this error comes up, nor how to fix it. Any ideas?

[0] lkml.kernel.org/r/1469222687-1600-1-git-send-email-mcgrof@kernel.org

  Luis

[toc] | [next] | [standalone]

#1458740

On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote:
> Mark, Aurelien,
>
> I've run into a linker (ld) issue caused by the linker table work I've
> been working on [0]. I looked into this and for the life of me, I
> cannot comprehend what the problem is, so was hoping you folks might
> be able to chime in.
>

For reference, the error is

c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined
c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined

Toolchain used is:

c6x-elf-gcc (GCC) 5.2.0
GNU ld (GNU Binutils) 2.25

Guenter

> A snapshot you can use is available here:
>
> https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160808-linker-table-v4
>
> The commit that causes the issue is "firmware: port built-in section
> to linker table":
>
> https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20160808-linker-table-v4&id=2f4516be8c89b3ca008962798d44b54751e62844
>
> its the first use of linker tables in the kernel, but I can't figure
> out why this error comes up, nor how to fix it. Any ideas?
>
> [0] lkml.kernel.org/r/1469222687-1600-1-git-send-email-mcgrof@kernel.org
>
>   Luis
>

[toc] | [prev] | [next] | [standalone]

#1458989

On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote:
> On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote:
> > 
> > Mark, Aurelien,
> > 
> > I've run into a linker (ld) issue caused by the linker table work I've
> > been working on [0]. I looked into this and for the life of me, I
> > cannot comprehend what the problem is, so was hoping you folks might
> > be able to chime in.
> > 
> For reference, the error is
> 
> c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined
> c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined

DSBT is a reference to the no-MMU userspace ABI used by c6x. The kernel shouldn't
be referencing DSBT base. The -mno-dsbt gcc flag should prevent it.

> 
> Toolchain used is:
> 
> c6x-elf-gcc (GCC) 5.2.0
> GNU ld (GNU Binutils) 2.25
> 
> Guenter
> 
> > 
> > A snapshot you can use is available here:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160808-linker-table-v4
> > 
> > The commit that causes the issue is "firmware: port built-in section
> > to linker table":
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20160808-linker-table-v4&id=2f4516be8c89b3ca008962798d44b54751e62844
> > 
> > its the first use of linker tables in the kernel, but I can't figure
> > out why this error comes up, nor how to fix it. Any ideas?
> > 
> > [0] lkml.kernel.org/r/1469222687-1600-1-git-send-email-mcgrof@kernel.org
> > 
> >   Luis
> > 

[toc] | [prev] | [next] | [standalone]

#1459056

On Tue, 2016-08-09 at 20:40 +0200, Luis R. Rodriguez wrote:
> On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote:
> > 
> > On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote:
> > > 
> > > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote:
> > > > 
> > > > 
> > > > Mark, Aurelien,
> > > > 
> > > > I've run into a linker (ld) issue caused by the linker table work I've
> > > > been working on [0]. I looked into this and for the life of me, I
> > > > cannot comprehend what the problem is, so was hoping you folks might
> > > > be able to chime in.
> > > > 
> > > For reference, the error is
> > > 
> > > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined
> > > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined
> > DSBT is a reference to the no-MMU userspace ABI used by c6x. The kernel shouldn't
> > be referencing DSBT base. The -mno-dsbt gcc flag should prevent it.
> I see -mno-dsbt on arch/c6x/Makefile already -- however at link time this is
> an issue if linker tables are used it seems. Do you have any other recommendation?
> 

I'm looking at it now...

> I will note that it would seem that even i386 and x86-64 compiler/binutils seem
> to have relocation issues on older compiler/binutils, for instance:
> 
> gcc-4.7.2
> binutils-2.22 
> 
> Yields:
> 
> x86_64:allyesconfig || x86_64:allmodconfig
> Invalid absolute R_X86_64_64 relocation: __per_cpu_load 
> 
> i386:defconfig
> Invalid absolute R_386_32 relocation: __vvar_page
> 
> This issue on x86 is not observed as so far as of gcc 5.2.1
> and binutils-2.26.1.
> 
> hpa -- if you can think of a work around for this for older compilers/linkers
> let me know... unless we are OK to increase the requirements for x86.
> 
>   Luis

[toc] | [prev] | [next] | [standalone]

#1459059

On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote:
> On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote:
> > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote:
> > > 
> > > Mark, Aurelien,
> > > 
> > > I've run into a linker (ld) issue caused by the linker table work I've
> > > been working on [0]. I looked into this and for the life of me, I
> > > cannot comprehend what the problem is, so was hoping you folks might
> > > be able to chime in.
> > > 
> > For reference, the error is
> > 
> > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined
> > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined
> 
> DSBT is a reference to the no-MMU userspace ABI used by c6x. The kernel shouldn't
> be referencing DSBT base. The -mno-dsbt gcc flag should prevent it.

I see -mno-dsbt on arch/c6x/Makefile already -- however at link time this is
an issue if linker tables are used it seems. Do you have any other recommendation?

I will note that it would seem that even i386 and x86-64 compiler/binutils seem
to have relocation issues on older compiler/binutils, for instance:

gcc-4.7.2
binutils-2.22 

Yields:

x86_64:allyesconfig || x86_64:allmodconfig
Invalid absolute R_X86_64_64 relocation: __per_cpu_load 

i386:defconfig
Invalid absolute R_386_32 relocation: __vvar_page

This issue on x86 is not observed as so far as of gcc 5.2.1
and binutils-2.26.1.

hpa -- if you can think of a work around for this for older compilers/linkers
let me know... unless we are OK to increase the requirements for x86.

  Luis

[toc] | [prev] | [next] | [standalone]

#1459240

On Tue, 2016-08-09 at 20:40 +0200, Luis R. Rodriguez wrote:
> On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote:
> > 
> > On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote:
> > > 
> > > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote:
> > > > 
> > > > 
> > > > Mark, Aurelien,
> > > > 
> > > > I've run into a linker (ld) issue caused by the linker table work I've
> > > > been working on [0]. I looked into this and for the life of me, I
> > > > cannot comprehend what the problem is, so was hoping you folks might
> > > > be able to chime in.
> > > > 
> > > For reference, the error is
> > > 
> > > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined
> > > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined
> > DSBT is a reference to the no-MMU userspace ABI used by c6x. The kernel shouldn't
> > be referencing DSBT base. The -mno-dsbt gcc flag should prevent it.
> I see -mno-dsbt on arch/c6x/Makefile already -- however at link time this is
> an issue if linker tables are used it seems. Do you have any other recommendation?
> 
> I will note that it would seem that even i386 and x86-64 compiler/binutils seem
> to have relocation issues on older compiler/binutils, for instance:

I see the problem with gcc 6 as well.

So there appears to be some toolchain issues at play here. We build the kernel with two
c6x-specific options: -mno-dsbt and -msdata=none. I already mentioned dsbt. The sdata
option may be one of:

-msdata=default
     Put small global and static data in the .neardata section, which is pointed to by
     register B14. Put small uninitialized global and static data in the .bss section,
     which is adjacent to the .neardata section. Put small read-only data into the 
     .rodata section. The corresponding sections used for large pieces of data are
     .fardata, .far and .const.

-msdata=all
    Put all data, not just small objects, into the sections reserved for small data,
    and use addressing relative to the B14 register to access them.

-msdata=none
    Make no use of the sections reserved for small data, and use absolute addresses
    to access all data. Put all initialized global and static data in the .fardata
    section, and all uninitialized data in the .far section. Put all constant data
    into the .const section.


Both small data and DSBT make use of base register + 15-bit offset to access data
and thus the SB-relative reloc in the above error message.

I think that gcc sees the .rodata section from DEFINE_LINKTABLE_RO() for builtin_fw
and thinks it needs an SB-relative reloc. When the linker sees that reloc, it thinks
it needs the dsbt base register and thus the error. Interestingly, weak data is
never put in the small data section so if gcc sees that data is weak, it doesn't
check the section name to see if it is a small data section. So SB-relative only
gets used for builtin_fw__end, but not the weak builtin_fw even though they both
are in the .rodata section.

I suspect gcc should avoid being fooled by .rodata if -msdata=none is used.
Regardless, I think this could all be avoided if the RO tables used .const
instead of .rodata for c6x.


> gcc-4.7.2
> binutils-2.22 
> 
> Yields:
> 
> x86_64:allyesconfig || x86_64:allmodconfig
> Invalid absolute R_X86_64_64 relocation: __per_cpu_load 
> 
> i386:defconfig
> Invalid absolute R_386_32 relocation: __vvar_page
> 
> This issue on x86 is not observed as so far as of gcc 5.2.1
> and binutils-2.26.1.
> 
> hpa -- if you can think of a work around for this for older compilers/linkers
> let me know... unless we are OK to increase the requirements for x86.
> 
>   Luis

[toc] | [prev] | [next] | [standalone]

#1459253

On Tue, 2016-08-09 at 19:09 -0700, Luis R. Rodriguez wrote:
> On Aug 9, 2016 6:50 PM, "Mark Salter" <msalter@redhat.com> wrote:
> >
> > On Tue, 2016-08-09 at 20:40 +0200, Luis R. Rodriguez wrote:
> > > On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote:
> > > >
> > > > On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote:
> > > > >
> > > > > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote:
> > > > > >
> > > > > >
> > > > > > Mark, Aurelien,
> > > > > >
> > > > > > I've run into a linker (ld) issue caused by the linker table work I've
> > > > > > been working on [0]. I looked into this and for the life of me, I
> > > > > > cannot comprehend what the problem is, so was hoping you folks might
> > > > > > be able to chime in.
> > > > > >
> > > > > For reference, the error is
> > > > >
> > > > > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined
> > > > > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined
> > > > DSBT is a reference to the no-MMU userspace ABI used by c6x. The kernel shouldn't
> > > > be referencing DSBT base. The -mno-dsbt gcc flag should prevent it.
> > > I see -mno-dsbt on arch/c6x/Makefile already -- however at link time this is
> > > an issue if linker tables are used it seems. Do you have any other recommendation?
> > >
> > > I will note that it would seem that even i386 and x86-64 compiler/binutils seem
> > > to have relocation issues on older compiler/binutils, for instance:
> >
> > I see the problem with gcc 6 as well.
> >
> > So there appears to be some toolchain issues at play here. We build the kernel with two
> > c6x-specific options: -mno-dsbt and -msdata=none. I already mentioned dsbt. The sdata
> > option may be one of:
> >
> > -msdata=default
> >      Put small global and static data in the .neardata section, which is pointed to by
> >      register B14. Put small uninitialized global and static data in the .bss section,
> >      which is adjacent to the .neardata section. Put small read-only data into the 
> >      .rodata section. The corresponding sections used for large pieces of data are
> >      .fardata, .far and .const.
> >
> > -msdata=all
> >     Put all data, not just small objects, into the sections reserved for small data,
> >     and use addressing relative to the B14 register to access them.
> >
> > -msdata=none
> >     Make no use of the sections reserved for small data, and use absolute addresses
> >     to access all data. Put all initialized global and static data in the .fardata
> >     section, and all uninitialized data in the .far section. Put all constant data
> >     into the .const section.
> >
> >
> > Both small data and DSBT make use of base register + 15-bit offset to access data
> > and thus the SB-relative reloc in the above error message.
> >
> > I think that gcc sees the .rodata section from DEFINE_LINKTABLE_RO() for builtin_fw
> > and thinks it needs an SB-relative reloc. When the linker sees that reloc, it thinks
> > it needs the dsbt base register and thus the error. Interestingly, weak data is
> > never put in the small data section so if gcc sees that data is weak, it doesn't
> > check the section name to see if it is a small data section. So SB-relative only
> > gets used for builtin_fw__end, but not the weak builtin_fw even though they both
> > are in the .rodata section.
> >
> > I suspect gcc should avoid being fooled by .rodata if -msdata=none is used.
> > Regardless, I think this could all be avoided if the RO tables used .const
> > instead of .rodata for c6x.
> Thanks for the thorough analysis, would you be OK for c6x to use .const for all read only linker tables or section ranges ?
> I had not added #ifndef around the core-sections.h main ELF definitons but could add one as its needed. In this case perhals that is needed and fine by you
> for SECTION_RODATA.
> We can also override any of the core section setter helpers for archs but in this case based on what you say it seems this is needed. Unless of course just
> -msdata=none is fine and that's not yet used and you prefer that.
>   Luis

We're already using -msdata=none for kernel builds. From the gcc docs, one would think
all const data goes into .const with -msdata=none, but the kernel forces a lot of weak
const kallsyms data ,rodata so c6x vmlinux.lds still needs to have a .rodata section. I
think we need to use .const for the c6x read-only linker tables and keep .rodata for
RO_DATA_SECTION in vmlinux.lds.h.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web