Re: Failed to build linux-2.6.34-rc5 when CONFIG_RELOCATABLE=y using gold

Re: Failed to build linux-2.6.34-rc5 when CONFIG_RELOCATABLE=y using gold

[Wenji Huang]

> On 05/12/2010 01:05 PM, Ian Lance Taylor wrote:
>> Randy Dunlap<randy.dunlap@oracle.com>  writes:
>>
>>> FYI:  a reported modprobe bug when using gold:
>>>    https://bugzilla.kernel.org/show_bug.cgi?id=15466
> The declaration and reference:
>
> extern struct builtin_fw __start_builtin_fw[];
> for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++)
>
> But the definition is in linker script.
>
>  . = ALIGN(((1 << 12))); .rodata
> /*snip*/
> .builtin_fw : AT(ADDR(.builtin_fw) - 0xC0000000) { __start_builtin_fw
> = .; *(.builtin_fw) __end_builtin_fw = .; }
>
> Once we removed the reference of __start_builtin_fw, it won't exist in
> absolute symbol table. I don't understand how gold will deal with the
> case and fix it either.
>
>Thanks for looking into this.
>
>I don't quite understand what you are saying.  Are you saying that
>gold is generating __start_builtin_fw as an absolute symbol rather
>than as a section relative symbol, and that that is causing the
>problem with the kernel?
>
>Ian

Yes, the warning message is in my previous email. Some absolute
symbols are generated.

  LD      vmlinux
  SYSMAP  System.map
  SYSMAP  .tmp_System.map
  VOFFSET arch/x86/boot/voffset.h
  OBJCOPY arch/x86/boot/compressed/vmlinux.bin
  RELOCS  arch/x86/boot/compressed/vmlinux.relocs
WARNING: Absolute relocations present
Offset     Info     Type     Sym.Value Sym.Name
c101c4de 007e5201   R_386_32 c144f000  __init_end
c101c4e3 007e5301   R_386_32 c13f3000  __init_begin
c104fe83 0085a501   R_386_32 c139387c  __start___kcrctab_gpl_future
c104fee4 0085ac01   R_386_32 c138f4dc  __start___ksymtab_gpl_future
c104feec 0085ad01   R_386_32 c138f4dc  __stop___ksymtab_gpl_future
c11ae76f 00a39401   R_386_32 c1386d9c  __start_builtin_fw
c11ae78d 00a39501   R_386_32 c1386d9c  __end_builtin_fw
c1402ae9 007e5201   R_386_32 c144f000  __init_end
c1402aef 007e5301   R_386_32 c13f3000  __init_begin
c1402b8d 007e5201   R_386_32 c144f000  __init_end
c1402b92 007e5301   R_386_32 c13f3000  __init_begin
c1402ddc 007e5201   R_386_32 c144f000  __init_end
c1402de8 007e5201   R_386_32 c144f000  __init_end
c1402ecd 007e5201   R_386_32 c144f000  __init_end

This is the problem with kernel.

Regards,
Wenji

Re: Failed to build linux-2.6.34-rc5 when CONFIG_RELOCATABLE=y using gold

[Ian Lance Taylor]

Wenji Huang <wenji.huang@oracle.com> writes:

> On 05/12/2010 01:05 PM, Ian Lance Taylor wrote:
>> Randy Dunlap<randy.dunlap@oracle.com>  writes:
>>
>>> FYI:  a reported modprobe bug when using gold:
>>>    https://bugzilla.kernel.org/show_bug.cgi?id=15466
>>
>> Thanks for letting me know about these issues.
>>
>> Unfortunately, there is essentially nothing I can do to fix it.  I
>> have neither the time nor the expertise to debug kernel problems.  If
>> people familiar with the kernel can pin down the difference between
>> what GNU ld and gold are doing, such that gold causes a failure, that
>> would be extremely helpful.  The differences tend to be due to
>> undocumented linker script behaviour or disagreements about alignment.
>>
>> Ian
>>
> Hi,
>
> I made some tests, found the clue. The absolute symbol seems from the
> following combination. For example,
>
> The declaration and reference:
>
> extern struct builtin_fw __start_builtin_fw[];
> for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++)
>
> But the definition is in linker script.
>
>  . = ALIGN(((1 << 12))); .rodata
> /*snip*/
> .builtin_fw : AT(ADDR(.builtin_fw) - 0xC0000000) { __start_builtin_fw
> = .; *(.builtin_fw) __end_builtin_fw = .; }
>
> Once we removed the reference of __start_builtin_fw, it won't exist in
> absolute symbol table. I don't understand how gold will deal with the
> case and fix it either.

Thanks for looking into this.

I don't quite understand what you are saying.  Are you saying that
gold is generating __start_builtin_fw as an absolute symbol rather
than as a section relative symbol, and that that is causing the
problem with the kernel?

Ian

Re: Failed to build linux-2.6.34-rc5 when CONFIG_RELOCATABLE=y using gold

[Wenji Huang]

On 05/12/2010 01:05 PM, Ian Lance Taylor wrote:
> Randy Dunlap<randy.dunlap@oracle.com>  writes:
>
>> FYI:  a reported modprobe bug when using gold:
>>    https://bugzilla.kernel.org/show_bug.cgi?id=15466
>
> Thanks for letting me know about these issues.
>
> Unfortunately, there is essentially nothing I can do to fix it.  I
> have neither the time nor the expertise to debug kernel problems.  If
> people familiar with the kernel can pin down the difference between
> what GNU ld and gold are doing, such that gold causes a failure, that
> would be extremely helpful.  The differences tend to be due to
> undocumented linker script behaviour or disagreements about alignment.
>
> Ian
>
Hi,

I made some tests, found the clue. The absolute symbol seems from the 
following combination. For example,

The declaration and reference:

extern struct builtin_fw __start_builtin_fw[];
for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++)

But the definition is in linker script.

  . = ALIGN(((1 << 12))); .rodata
/*snip*/
.builtin_fw : AT(ADDR(.builtin_fw) - 0xC0000000) { __start_builtin_fw = 
.; *(.builtin_fw) __end_builtin_fw = .; }

Once we removed the reference of __start_builtin_fw, it won't exist in
absolute symbol table. I don't understand how gold will deal with the
case and fix it either.

Regards,
Wenji

Re: Failed to build linux-2.6.34-rc5 when CONFIG_RELOCATABLE=y using gold

[Ian Lance Taylor]

Randy Dunlap <randy.dunlap@oracle.com> writes:

> FYI:  a reported modprobe bug when using gold:
>   https://bugzilla.kernel.org/show_bug.cgi?id=15466

Thanks for letting me know about these issues.

Unfortunately, there is essentially nothing I can do to fix it.  I
have neither the time nor the expertise to debug kernel problems.  If
people familiar with the kernel can pin down the difference between
what GNU ld and gold are doing, such that gold causes a failure, that
would be extremely helpful.  The differences tend to be due to
undocumented linker script behaviour or disagreements about alignment.

Ian

Re: Failed to build linux-2.6.34-rc5 when CONFIG_RELOCATABLE=y using gold

[Randy Dunlap]

On 05/04/10 01:32, Wenji Huang wrote:
> On 04/20/2010 04:44 PM, Wenji Huang wrote:
>> Hi,
>>
>> I tried gold as the linker to build linux-2.6.34-rc5 and found that
>> if I set CONFIG_RELOCATABLE=y, there will be warning like
>>
>> gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
>> GNU gold (GNU Binutils 2.20.1.20100303) 1.9
>>
>> HOSTCC arch/x86/boot/compressed/relocs
>> CC drivers/scsi/scsi_wait_scan.mod.o
>> CC fs/btrfs/btrfs.mod.o
>> HOSTCC arch/x86/boot/compressed/mkpiggy
>> RELOCS arch/x86/boot/compressed/vmlinux.relocs
>> CC fs/configfs/configfs.mod.o
>> WARNING: Absolute relocations present
>> Offset Info Type Sym.Value Sym.Name
>> c101b0d0 00a94b01 R_386_32 c1655000 __init_end
>> c101b0d5 00a94c01 R_386_32 c15d3000 __init_begin
>> c101b1be 00a94b01 R_386_32 c1655000 __init_end
>> c15df7ce 00a94b01 R_386_32 c1655000 __init_end
>> c15df7d4 00a94c01 R_386_32 c15d3000 __init_begin
>> c15df871 00a94b01 R_386_32 c1655000 __init_end
>> c15df876 00a94c01 R_386_32 c15d3000 __init_begin
>> c13b2848 00af1701 R_386_32 c155088c __start___kcrctab
>> c13b285c 00af1a01 R_386_32 c155088c __start___kcrctab_gpl
>> c13b2868 00af1b01 R_386_32 c155088c __start___ksymtab_gpl_future
>> c13b286c 00af1c01 R_386_32 c155088c __stop___ksymtab_gpl_future
>> c13b2870 00af1d01 R_386_32 c155088c __start___kcrctab_gpl_future
>>
>> GZIP arch/x86/boot/compressed/vmlinux.bin.gz
>>
>> And the built kernel can't start up. But if unset CONFIG_RELOCATABLE,
>> the warning will disappear and kernel can work well.
>>
>> Regards,
>> Wenji
> 
> Same result on 2.6.34-rc6, using gold of binutils 2.20.51 snapshots.
> But works well using ld instead.
> 
> Regards,
> Wenji

FYI:  a reported modprobe bug when using gold:
  https://bugzilla.kernel.org/show_bug.cgi?id=15466

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: Failed to build linux-2.6.34-rc5 when CONFIG_RELOCATABLE=y using gold

[Wenji Huang]

On 04/20/2010 04:44 PM, Wenji Huang wrote:
> Hi,
>
> I tried gold as the linker to build linux-2.6.34-rc5 and found that
> if I set CONFIG_RELOCATABLE=y, there will be warning like
>
> gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
> GNU gold (GNU Binutils 2.20.1.20100303) 1.9
>
> HOSTCC arch/x86/boot/compressed/relocs
> CC drivers/scsi/scsi_wait_scan.mod.o
> CC fs/btrfs/btrfs.mod.o
> HOSTCC arch/x86/boot/compressed/mkpiggy
> RELOCS arch/x86/boot/compressed/vmlinux.relocs
> CC fs/configfs/configfs.mod.o
> WARNING: Absolute relocations present
> Offset Info Type Sym.Value Sym.Name
> c101b0d0 00a94b01 R_386_32 c1655000 __init_end
> c101b0d5 00a94c01 R_386_32 c15d3000 __init_begin
> c101b1be 00a94b01 R_386_32 c1655000 __init_end
> c15df7ce 00a94b01 R_386_32 c1655000 __init_end
> c15df7d4 00a94c01 R_386_32 c15d3000 __init_begin
> c15df871 00a94b01 R_386_32 c1655000 __init_end
> c15df876 00a94c01 R_386_32 c15d3000 __init_begin
> c13b2848 00af1701 R_386_32 c155088c __start___kcrctab
> c13b285c 00af1a01 R_386_32 c155088c __start___kcrctab_gpl
> c13b2868 00af1b01 R_386_32 c155088c __start___ksymtab_gpl_future
> c13b286c 00af1c01 R_386_32 c155088c __stop___ksymtab_gpl_future
> c13b2870 00af1d01 R_386_32 c155088c __start___kcrctab_gpl_future
>
> GZIP arch/x86/boot/compressed/vmlinux.bin.gz
>
> And the built kernel can't start up. But if unset CONFIG_RELOCATABLE,
> the warning will disappear and kernel can work well.
>
> Regards,
> Wenji

Same result on 2.6.34-rc6, using gold of binutils 2.20.51 snapshots.
But works well using ld instead.

Regards,
Wenji

Failed to build linux-2.6.34-rc5 when CONFIG_RELOCATABLE=y using gold

[Wenji Huang]

Hi,

I tried gold as the linker to build linux-2.6.34-rc5 and found that
if I set CONFIG_RELOCATABLE=y, there will be warning like

gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
GNU gold (GNU Binutils 2.20.1.20100303) 1.9

   HOSTCC  arch/x86/boot/compressed/relocs
   CC      drivers/scsi/scsi_wait_scan.mod.o
   CC      fs/btrfs/btrfs.mod.o
   HOSTCC  arch/x86/boot/compressed/mkpiggy
   RELOCS  arch/x86/boot/compressed/vmlinux.relocs
   CC      fs/configfs/configfs.mod.o
WARNING: Absolute relocations present
Offset     Info     Type     Sym.Value Sym.Name
c101b0d0 00a94b01   R_386_32 c1655000  __init_end
c101b0d5 00a94c01   R_386_32 c15d3000  __init_begin
c101b1be 00a94b01   R_386_32 c1655000  __init_end
c15df7ce 00a94b01   R_386_32 c1655000  __init_end
c15df7d4 00a94c01   R_386_32 c15d3000  __init_begin
c15df871 00a94b01   R_386_32 c1655000  __init_end
c15df876 00a94c01   R_386_32 c15d3000  __init_begin
c13b2848 00af1701   R_386_32 c155088c  __start___kcrctab
c13b285c 00af1a01   R_386_32 c155088c  __start___kcrctab_gpl
c13b2868 00af1b01   R_386_32 c155088c  __start___ksymtab_gpl_future
c13b286c 00af1c01   R_386_32 c155088c  __stop___ksymtab_gpl_future
c13b2870 00af1d01   R_386_32 c155088c  __start___kcrctab_gpl_future

   GZIP    arch/x86/boot/compressed/vmlinux.bin.gz

And the built kernel can't start up. But if unset CONFIG_RELOCATABLE,
the warning will disappear and kernel can work well.

Regards,
Wenji