Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Török Edwin]

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

Hi,

I tried to link the Linux kernel with gold.
Everything went fine with linking, however after rebooting the kernel 
wasn't working: it instantly rebooted as soon as I selected it from grub.

I thought its better to bring up this issue here on the ML, rather than 
in a bug, because the bugreport wouldn've been pretty useless.

How can I track down what the problem is with gold here?
Has anyone encountered a similar issue before (has anyone got a working 
kernel with gold)?

I don't think I ever got a working kernel with gold.
Last time I tried there were some linking issues with fglrx, I opened a 
bug, and it got fixed.
Meanwhile I no longer use fglrx (switched to open source radeon 
drivers), so everything links fine, but doesn't boot.

I tried with 2.6.33, 2.6.34-rc3, and v2.6.34-rc3-138-gecb385a.

This is the gold version I am using:
GNU gold (GNU Binutils for Debian 2.20.1-system.20100303) 1.9

If I remove gold, and link with the usual ld (GNU ld (GNU Binutils for 
Debian) 2.20.1-system.20100303), then all these kernels boot fine.

This is my gcc version:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-7' 
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--enable-shared --enable-multiarch --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 
--program-suffix=-4.4 --enable-nls --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-plugin --enable-objc-gc 
--with-arch-32=i486 --with-tune=generic --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Debian 4.4.3-7)

I've attached the .config I used for the kernel, if someone wants to 
reproduce the bug.

Best regards,
--Edwin

[-- Attachment #2: .config.gz --]
[-- Type: application/x-gzip, Size: 15112 bytes --]

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Ian Lance Taylor]

Török Edwin <edwintorok@gmail.com> writes:

> I tried to link the Linux kernel with gold.
> Everything went fine with linking, however after rebooting the kernel
> wasn't working: it instantly rebooted as soon as I selected it from
> grub.

> How can I track down what the problem is with gold here?
> Has anyone encountered a similar issue before (has anyone got a
> working kernel with gold)?

People have gotten working kernels with gold.  The kernel and gold
move in and out of working together.  The kernel uses several
extremely obscure and undocumented linker script features.  As they
change the linker scripts, the build sometimes stops working.

The usual approach to fixing the bug is to compare the kernel
generated by GNU ld with the one generated by gold.  The problem is
invariably one of the output files generated by a linker script.  So
look at those files.  Look for significant differences in size.  Look
at the section headers and look for differences in alignment.  If that
doesn't help you may need to figure out what is crashing, but I can't
help with that.


> This is the gold version I am using:
> GNU gold (GNU Binutils for Debian 2.20.1-system.20100303) 1.9

Use mainline instead.  There have been quite a few bug fixes since the
2.20 release.  The 2.20 release is fine for most uses, but not for the
kernel.

Ian

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Doug Kwan (關振德)]

I am actually working on a similar problem.  The compressed ARM Linux
kernel is not bootable because it assumes entry point is at address 0.
 Unfortunately in script processing we move stuff around and we end up
having a bunch of strings from .rodata input sections in address 0.
Since compressed kernel does not have the ELF file header, there is no
way to specify the correct entry point.  I am working on a fix for
this problem.

-Doug

2010/4/9 Ian Lance Taylor <iant@google.com>:
> Török Edwin <edwintorok@gmail.com> writes:
>
>> I tried to link the Linux kernel with gold.
>> Everything went fine with linking, however after rebooting the kernel
>> wasn't working: it instantly rebooted as soon as I selected it from
>> grub.
>
>> How can I track down what the problem is with gold here?
>> Has anyone encountered a similar issue before (has anyone got a
>> working kernel with gold)?
>
> People have gotten working kernels with gold.  The kernel and gold
> move in and out of working together.  The kernel uses several
> extremely obscure and undocumented linker script features.  As they
> change the linker scripts, the build sometimes stops working.
>
> The usual approach to fixing the bug is to compare the kernel
> generated by GNU ld with the one generated by gold.  The problem is
> invariably one of the output files generated by a linker script.  So
> look at those files.  Look for significant differences in size.  Look
> at the section headers and look for differences in alignment.  If that
> doesn't help you may need to figure out what is crashing, but I can't
> help with that.
>
>
>> This is the gold version I am using:
>> GNU gold (GNU Binutils for Debian 2.20.1-system.20100303) 1.9
>
> Use mainline instead.  There have been quite a few bug fixes since the
> 2.20 release.  The 2.20 release is fine for most uses, but not for the
> kernel.
>
> Ian
>

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Török Edwin]

[-- Attachment #1: Type: text/plain, Size: 4664 bytes --]

On 04/10/2010 01:24 AM, Ian Lance Taylor wrote:
> Török Edwin<edwintorok@gmail.com>  writes:
>
>> I tried to link the Linux kernel with gold.
>> Everything went fine with linking, however after rebooting the kernel
>> wasn't working: it instantly rebooted as soon as I selected it from
>> grub.
>
>> How can I track down what the problem is with gold here?
>> Has anyone encountered a similar issue before (has anyone got a
>> working kernel with gold)?
>
> People have gotten working kernels with gold.  The kernel and gold
> move in and out of working together.  The kernel uses several
> extremely obscure and undocumented linker script features.  As they
> change the linker scripts, the build sometimes stops working.
>
> The usual approach to fixing the bug is to compare the kernel
> generated by GNU ld with the one generated by gold.  The problem is
> invariably one of the output files generated by a linker script.  So
> look at those files.  Look for significant differences in size.

Here you go, looks like gold dropped 1/3 of the kernel:
-rwxr-xr-x 1 edwin edwin 11M Apr 10 15:38 vmlinux.gold
-rwxr-xr-x 1 edwin edwin 17M Apr 10 15:37 vmlinux.bfd

>  Look
> at the section headers and look for differences in alignment.  If that
> doesn't help you may need to figure out what is crashing, but I can't
> help with that.

I found an easier way to test than rebooting the real system:
kvm -kernel arch/x86/boot/bzImage

If I take the linker command used to create vmlinux, and use the usual 
LD linker to create it, then the kernel starts booting in qemu/kvm.
With gold it instantly reboots.

I diffed the readelf output, and attached it (without the actual symbol 
address diffs, those are huge):
Here are some highlights (- is gold/bad, + is bfd/good):
  offset differences:
  [Nr] Name                 Type         Addr             Off      Size 
     ES Flags Lk Inf A
-[ 1] .text                PROGBITS     ffffffff81000000 00001000 
003d1c55  0 AX     0   0 4096
+[ 1] .text                PROGBITS     ffffffff81000000 00200000 
003d1c55  0 AX     0   0 4096

  alignment differences:
  Program Headers:
    Type           Offset   VirtAddr           PhysAddr 
FileSiz  MemSiz   Flg Align
-  LOAD           0x001000 0xffffffff81000000 0x0000000001000000 
0x5f2000 0x5f2000 R E 0x1000
-  LOAD           0x5f3000 0xffffffff81600000 0x0000000001600000 
0x183220 0x183220 RWE 0x1000
-  LOAD           0x777000 0xffffffffff600000 0x0000000001784000 
0x000888 0x000888 R E 0x1000
-  LOAD           0x778000 0x0000000000000000 0x0000000001785000 
0x014628 0x014628 RW  0x1000
-  LOAD           0x78d000 0xffffffff8179a000 0x000000000179a000 
0x071000 0x456d000 RWE 0x1000
-  NOTE           0x3d2c58 0xffffffff813d1c58 0x00000000013d1c58 
0x00003c 0x00003c     0x4
+  LOAD           0x200000 0xffffffff81000000 0x0000000001000000 
0x5ef000 0x5ef000 R E 0x200000
+  LOAD           0x800000 0xffffffff81600000 0x0000000001600000 
0x183220 0x183220 RWE 0x200000
+  LOAD           0xa00000 0xffffffffff600000 0x0000000001784000 
0x000888 0x000888 R E 0x200000
+  LOAD           0xc00000 0x0000000000000000 0x0000000001785000 
0x014628 0x014628 RW  0x200000
+  LOAD           0xd9a000 0xffffffff8179a000 0x000000000179a000 
0x071000 0x456d000 RWE 0x200000
+  NOTE           0x5d1c58 0xffffffff813d1c58 0x00000000013d1c58 
0x000024 0x000024     0x4

Do these ring any bells?

>
>
>> This is the gold version I am using:
>> GNU gold (GNU Binutils for Debian 2.20.1-system.20100303) 1.9
>
> Use mainline instead.  There have been quite a few bug fixes since the
> 2.20 release.  The 2.20 release is fine for most uses, but not for the
> kernel.

Thanks, I tried the latest CVS. It is still rebooting :(

Here is the link command for vmlinux:
ld -m elf_x86_64 --build-id  -o vmlinux -T arch/x86/kernel/vmlinux.lds 
arch/x86/kernel/head_64.o arch/x86/kernel/head64.o 
arch/x86/kernel/head.o arch/x86/kernel/init_task.o  init/built-in.o 
--start-group  usr/built-in.o  arch/x86/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/x86/lib/lib.a 
lib/built-in.o  arch/x86/lib/built-in.o  drivers/built-in.o 
sound/built-in.o  firmware/built-in.o  arch/x86/pci/built-in.o 
arch/x86/power/built-in.o  arch/x86/video/built-in.o  net/built-in.o 
--end-group .tmp_kallsyms2.o

I run that with gold vs system linker to reproduce the bug, then run 
make bzImage to create the vmlinuz out of it.

I have attached the vmlinux.lds script, but I don't know what I should 
be looking at there.
Should I open a bug and attach all these .o files too?

Best regards,
--Edwin

[-- Attachment #2: readelf.diff.gz --]
[-- Type: application/x-gzip, Size: 2206 bytes --]

[-- Attachment #3: vmlinux.lds.gz --]
[-- Type: application/x-gzip, Size: 8612 bytes --]

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[John Reiser]

> Here you go, looks like gold dropped 1/3 of the kernel:
> -rwxr-xr-x 1 edwin edwin 11M Apr 10 15:38 vmlinux.gold
> -rwxr-xr-x 1 edwin edwin 17M Apr 10 15:37 vmlinux.bfd

Not necessarily.  The 6M difference might be explained by a
combination of alignment in the file and/or symbol tables and/or
debugging information that need not be relevant to execution,
particularly for a kernel.

> [Nr] Name Type Addr Off Size ES Flags Lk Inf A
> -[ 1] .text PROGBITS ffffffff81000000 00001000 003d1c55 0 AX 0 0 4096
> +[ 1] .text PROGBITS ffffffff81000000 00200000 003d1c55 0 AX 0 0 4096

The difference in file offset between 0x1000 (4 KiB) and 0x200000 (2 MiB)
probably accounts for just under 2 MiB of zeroes in the file.  Such a
difference for file offset of Elf64_Shdr need not be relevant to execution
of a Linux kernel, as long as the 0x3d1c55 bytes of content are identical.

> alignment differences: [KEY:  -: gold;  +: ld]
> Program Headers:
>   Type   Offset           VirtAddr           PhysAddr  FileSiz   MemSiz Flg  Align
> - LOAD 0x001000 0xffffffff81000000 0x0000000001000000 0x5f2000 0x5f2000 R E 0x1000
> - LOAD 0x5f3000 0xffffffff81600000 0x0000000001600000 0x183220 0x183220 RWE 0x1000
> - LOAD 0x777000 0xffffffffff600000 0x0000000001784000 0x000888 0x000888 R E 0x1000
> - LOAD 0x778000 0x0000000000000000 0x0000000001785000 0x014628 0x014628 RW  0x1000
> - LOAD 0x78d000 0xffffffff8179a000 0x000000000179a000 0x071000 0x456d000 RWE 0x1000
> - NOTE 0x3d2c58 0xffffffff813d1c58 0x00000000013d1c58 0x00003c 0x00003c 0x4
> + LOAD 0x200000 0xffffffff81000000 0x0000000001000000 0x5ef000 0x5ef000 R E 0x200000
> + LOAD 0x800000 0xffffffff81600000 0x0000000001600000 0x183220 0x183220 RWE 0x200000
> + LOAD 0xa00000 0xffffffffff600000 0x0000000001784000 0x000888 0x000888 R E 0x200000
> + LOAD 0xc00000 0x0000000000000000 0x0000000001785000 0x014628 0x014628 RW  0x200000
> + LOAD 0xd9a000 0xffffffff8179a000 0x000000000179a000 0x071000 0x456d000 RWE 0x200000
> + NOTE 0x5d1c58 0xffffffff813d1c58 0x00000000013d1c58 0x000024 0x000024 0x4

The differing .p_align values of 0x1000 vs 0x200000 indicate that
gold has a bug interpreting the commands from the linker script
for alignment of Elf64_Phdr.  The .p_align applies to the .p_vaddr
and .p_paddr (which are related to address space at execution),
and not necessarily to .p_offset (which is related to file storage.)
For an ordinary ET_EXEC application or ET_DYN shared lib these are
connected by mmap(): the actual hardware page size must divide all
three of (.p_vaddr - .p_offset), (.p_paddr - .p_offset), .p_align.
For a Linux kernel they are connected by the boot loader: .p_vaddr
and .p_paddr must be divisible by the actual hardware page size,
but it could be OK for .p_offset to be anything as long as the
content (the interval of loaded bytes) was identical.  This looser
restriction requires a boot loader that processes each PT_LOAD
independently as "real bytes."  If the boot loader tries to do more
than one PT_LOAD at a time without carefully checking that the adjacency
in the input stream is compliant with the adjacency in the address space,
then that is a problem.  Also, if the boot loader is loading the
address space of some virtual machine by using mmap() on the host
machine, without a fallback for the case when mmap() fails, then
the more-stringent restrictions of "ordinary ET_EXEC" are relevant,
and thus gold's differing .p_align is an underlying bug.

The differing .p_filsz and .p_memsz of 0x3c vs 0x24 for the PT_NOTE
indicate that gold may have a bug there.  Examine the contents
(see Elf64_Nhdr in /usr/include/elf.h) to determine the added/omitted/
merged/changed content.

The differing .p_filesz and .p_memsz of 0x5f2000 vs 0x5ef000 for
the first PT_LOAD is a bug in gold.

-- 

Re: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Török Edwin]

On 01/-10/-28163 09:59 PM, John Reiser wrote:
>> Here you go, looks like gold dropped 1/3 of the kernel:
>> -rwxr-xr-x 1 edwin edwin 11M Apr 10 15:38 vmlinux.gold
>> -rwxr-xr-x 1 edwin edwin 17M Apr 10 15:37 vmlinux.bfd
>
> Not necessarily. The 6M difference might be explained by a
> combination of alignment in the file and/or symbol tables and/or
> debugging information that need not be relevant to execution,
> particularly for a kernel.

OK, lets compare bzImage then:
3446848 arch/x86/boot/bzImage.gold
3475136 /boot/vmlinuz-2.6.34-rc3-00138-gecb385a

The difference is not that big here.

>
>> [Nr] Name Type Addr Off Size ES Flags Lk Inf A
>> -[ 1] .text PROGBITS ffffffff81000000 00001000 003d1c55 0 AX 0 0 4096
>> +[ 1] .text PROGBITS ffffffff81000000 00200000 003d1c55 0 AX 0 0 4096
>
> The difference in file offset between 0x1000 (4 KiB) and 0x200000 (2 MiB)
> probably accounts for just under 2 MiB of zeroes in the file. Such a
> difference for file offset of Elf64_Shdr need not be relevant to execution
> of a Linux kernel, as long as the 0x3d1c55 bytes of content are identical.

Not identical, difference starts at byte 230:
-vmlinux.gold:     file format elf64-x86-64
+vmlinux.bfd:     file format elf64-x86-64
....
-ffffffff810000e1:      48 01 2d b8 c1 46 00    add 
%rbp,0x46c1b8(%rip)        # ffffffff8146c2a0 <trampoline_level4_pgt>
-ffffffff810000e8:      48 01 2d a9 d1 46 00    add 
%rbp,0x46d1a9(%rip)        # ffffffff8146d298 <trampoline_level4_pgt+0xff8>
+ffffffff810000e1:      48 01 2d b8 74 40 00    add 
%rbp,0x4074b8(%rip)        # ffffffff814075a0 <trampoline_level4_pgt>
+ffffffff810000e8:      48 01 2d a9 84 40 00    add 
%rbp,0x4084a9(%rip)        # ffffffff81408598 <trampoline_level4_pgt+0xff8>
  ffffffff810000ef:      e9 0c 00 00 00          jmpq   ffffffff81000100 
<secondary_startup_64>

It appears to be a difference in the address chosen for that global (and 
other globals later on).

Other than differences in addresses there is also difference in padding:
gold uses 00 00 90 90 (add %al, (%rax) nop nop), while BFD uses 90 90 90 
90 (4 nops).

That address *ff814075a0 is in .rodata:
  [Nr] Name                 Type         Addr             Off      Size 
     ES Flags Lk Inf Al
-[ 4] .rodata              PROGBITS     ffffffff81400000 00401000 
001b7262  0 A      0   0 64
+[ 4] .rodata              PROGBITS     ffffffff81400000 00600000 
001b4cb2  0 A      0   0 64

Which has the difference in alignment you noticed below.

>
>> alignment differences: [KEY: -: gold; +: ld]
>> Program Headers:
>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
>> - LOAD 0x001000 0xffffffff81000000 0x0000000001000000 0x5f2000
>> 0x5f2000 R E 0x1000
>> - LOAD 0x5f3000 0xffffffff81600000 0x0000000001600000 0x183220
>> 0x183220 RWE 0x1000
>> - LOAD 0x777000 0xffffffffff600000 0x0000000001784000 0x000888
>> 0x000888 R E 0x1000
>> - LOAD 0x778000 0x0000000000000000 0x0000000001785000 0x014628
>> 0x014628 RW 0x1000
>> - LOAD 0x78d000 0xffffffff8179a000 0x000000000179a000 0x071000
>> 0x456d000 RWE 0x1000
>> - NOTE 0x3d2c58 0xffffffff813d1c58 0x00000000013d1c58 0x00003c
>> 0x00003c 0x4
>> + LOAD 0x200000 0xffffffff81000000 0x0000000001000000 0x5ef000
>> 0x5ef000 R E 0x200000
>> + LOAD 0x800000 0xffffffff81600000 0x0000000001600000 0x183220
>> 0x183220 RWE 0x200000
>> + LOAD 0xa00000 0xffffffffff600000 0x0000000001784000 0x000888
>> 0x000888 R E 0x200000
>> + LOAD 0xc00000 0x0000000000000000 0x0000000001785000 0x014628
>> 0x014628 RW 0x200000
>> + LOAD 0xd9a000 0xffffffff8179a000 0x000000000179a000 0x071000
>> 0x456d000 RWE 0x200000
>> + NOTE 0x5d1c58 0xffffffff813d1c58 0x00000000013d1c58 0x000024
>> 0x000024 0x4
>
> The differing .p_align values of 0x1000 vs 0x200000 indicate that
> gold has a bug interpreting the commands from the linker script
> for alignment of Elf64_Phdr.

vmlinux.lds has this comment:
/*
  * On 64-bit, align RODATA to 2MB so that even with CONFIG_DEBUG_RODATA
  * we retain large page mappings for boundaries spanning kernel text, 
rodata
  * and data sections.
  *
  * However, kernel identity mappings will have different RWX permissions
  * to the pages mapping to text and to the pages padding (which are 
freed) the
  * text section. Hence kernel identity mappings will be broken to smaller
  * pages. For 64-bit, kernel text and kernel identity mappings are 
different,
  * so we can enable protection checks that come with CONFIG_DEBUG_RODATA,
  * as well as retain 2MB large page mappings for kernel text.
  */

If I read that correctly it means it uses hardware pages with a pagesize 
of 2MB for kernel text.
Since gold aligns only to 0x1000 perhaps the rodata ends up in the same 
hardware page as the .text.

I think these are the relevant align commands from the vmlinux.lds for 
.text and .rodata:
  .text : AT(ADDR(.text) - 0xffffffff80000000) {
...
} :text=0x9090
. = ALIGN(16); __ex_table : AT(ADDR(__ex_table) - 0xffffffff80000000) { 
__start___ex_table = .; *(__ex_table) __stop___ex_tab
le = .; } :text = 0x9090
  . = ALIGN((1 << 21));
  . = ALIGN(((1 << 12))); .rodata : AT(ADDR(.rodata) - 
0xffffffff80000000) { __start_rodata = .;

This also suggests that I should try with DEBUG_RODATA turned off.
Indeed without DEBUG_RODATA the kernel starts booting in KVM.

This is description of DEBUG_RODATA:
"Mark the kernel read-only data as write-protected in the pagetables,
in order to catch accidental (and incorrect) writes to such const data. 
This is recommended so that we can catch kernel bugs sooner.
If in doubt, say "Y"."

I think that the problem is that the kernel tries to write-protect the 
.rodata, thinking that it is aligned to 2MB, when in fact its not.


> The .p_align applies to the .p_vaddr
> and .p_paddr (which are related to address space at execution),
> and not necessarily to .p_offset (which is related to file storage.)
> For an ordinary ET_EXEC application or ET_DYN shared lib these are
> connected by mmap(): the actual hardware page size must divide all
> three of (.p_vaddr - .p_offset), (.p_paddr - .p_offset), .p_align.
> For a Linux kernel they are connected by the boot loader: .p_vaddr
> and .p_paddr must be divisible by the actual hardware page size,
> but it could be OK for .p_offset to be anything as long as the
> content (the interval of loaded bytes) was identical. This looser
> restriction requires a boot loader that processes each PT_LOAD
> independently as "real bytes." If the boot loader tries to do more
> than one PT_LOAD at a time without carefully checking that the adjacency
> in the input stream is compliant with the adjacency in the address space,
> then that is a problem. Also, if the boot loader is loading the
> address space of some virtual machine by using mmap() on the host
> machine, without a fallback for the case when mmap() fails, then
> the more-stringent restrictions of "ordinary ET_EXEC" are relevant,
> and thus gold's differing .p_align is an underlying bug.

If the hw pagesize is 2MB, then its not divisible, so its a bug.
Should I open a bugreport, or are there some patches to gold that I 
could try?

>
> The differing .p_filsz and .p_memsz of 0x3c vs 0x24 for the PT_NOTE
> indicate that gold may have a bug there. Examine the contents
> (see Elf64_Nhdr in /usr/include/elf.h) to determine the added/omitted/
> merged/changed content.
>
> The differing .p_filesz and .p_memsz of 0x5f2000 vs 0x5ef000 for
> the first PT_LOAD is a bug in gold.

I think the .note difference is just due to gold embedding its version:
-Note section [ 2] '.notes' of 60 bytes at offset 0x3d2c58:
+Note section [ 2] '.notes' of 36 bytes at offset 0x5d1c58:
    Owner          Data size  Type
-  GNU                    8  GNU_GOLD_VERSION
-    Linker version: gold 1.9
    GNU                   20  GNU_BUILD_ID
-    Build ID: a865af685f5222cdc17a28ea4e49d58b2185bc05
+    Build ID: 07b53da4e169ad1079080043ad72384fb80d0ea3

Thanks for the help,

Best regards,
--Edwin

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[John Reiser]

> Not identical, difference starts at byte 230:
> -vmlinux.gold: file format elf64-x86-64
> +vmlinux.bfd: file format elf64-x86-64
    ...
> It appears to be a difference in the address chosen for that global (and
> other globals later on).

Although the placement of globals chosen from a library need not be
identical, it would be comforting to verify that this is the only reason.
Try changing the link command to remove all *.a (extract and specify each
*.o explicitly).  Then there should be no difference.

> ... there is also difference in padding:
> gold uses 00 00 90 90 (add %al, (%rax) nop nop), while BFD uses 90 90 90
> 90 (4 nops).

That is a dispute over interpretation of the linker script:
       } :text=0x9090
The original spec was from the days when 2==sizeof(int), so padding was
a 16-bit value, thus 0x9090 was all that mattered.  Check the spec
for an update regarding width of padding.  In the meantime, try changing
the script to
       } :text=0x90909090
which should remove this source of differences.

> If I read that correctly it means it uses hardware pages with a pagesize
> of 2MB for kernel text.

Yes.

> Since gold aligns only to 0x1000 perhaps the rodata ends up in the same
> hardware page as the .text.
>
> I think these are the relevant align commands from the vmlinux.lds ...

> . = ALIGN((1 << 21));

It is a bug that gold does not propagate that alignment constraint
to the .p_align.

> If the hw pagesize is 2MB, then its not divisible, so its a bug.
> Should I open a bugreport, or are there some patches to gold that I
> could try?

Definitely open a bug report about ". = ALIGN((1 << 21));"

> I think the .note difference is just due to gold embedding its version:
> -Note section [ 2] '.notes' of 60 bytes at offset 0x3d2c58:
> +Note section [ 2] '.notes' of 36 bytes at offset 0x5d1c58:
> Owner Data size Type
> - GNU 8 GNU_GOLD_VERSION
> - Linker version: gold 1.9
> GNU 20 GNU_BUILD_ID
> - Build ID: a865af685f5222cdc17a28ea4e49d58b2185bc05
> + Build ID: 07b53da4e169ad1079080043ad72384fb80d0ea3

Again, it would be comforting to make a test run with GNU_GOLD_VERSION
omitted, to see if the .text becomes identical (except for Build ID)
with ld.

-- 

Re: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Török Edwin]

On 01/-10/-28163 09:59 PM, John Reiser wrote:
>> Not identical, difference starts at byte 230:
>> -vmlinux.gold: file format elf64-x86-64
>> +vmlinux.bfd: file format elf64-x86-64
> ...
>> It appears to be a difference in the address chosen for that global (and
>> other globals later on).
>
> Although the placement of globals chosen from a library need not be
> identical, it would be comforting to verify that this is the only reason.
> Try changing the link command to remove all *.a (extract and specify each
> *.o explicitly). Then there should be no difference.

There still is. The size of the .rodata is different, so probably the 
order is still different too.

Does gold do some optimizations that bfd ld doesn't do? (such as 
dropping unneeded globals, reordering the globals to not waste space due 
to alignment, if it can put another global inbetween, etc.)

This is the commandline I used (using /usr/bin/ld vs /usr/local/bin/ld):
/usr/bin/ld --build-id -m elf_x86_64  -o vmlinux.bfd -T 
arch/x86/kernel/vmlinux.lds arch/x86/kernel/head_64.o 
arch/x86/kernel/head64.o arch/x86/kernel/head.o 
arch/x86/kernel/init_task.o  init/built-in.o --start-group 
usr/built-in.o  arch/x86/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  as/*.o lib/built-in.o  arch/x86/lib/built-in.o 
drivers/built-in.o  sound/built-in.o  firmware/built-in.o 
arch/x86/pci/built-in.o  arch/x86/power/built-in.o 
arch/x86/video/built-in.o  net/built-in.o --end-group .tmp_kallsyms2.o

I still have differences:
-ffffffff810000e1:      48 01 2d 08 c0 46 00    add 
%rbp,0x46c008(%rip)        # ffffffff8146c0f0 <trampoline_level4_pgt>
-ffffffff810000e8:      48 01 2d f9 cf 46 00    add 
%rbp,0x46cff9(%rip)        # ffffffff8146d0e8 <trampoline_level4_pgt+0xff8>
+ffffffff810000e1:      48 01 2d 98 74 40 00    add 
%rbp,0x407498(%rip)        # ffffffff81407580 <trampoline_level4_pgt>
+ffffffff810000e8:      48 01 2d 89 84 40 00    add 
%rbp,0x408489(%rip)        # ffffffff81408578 <trampoline_level4_pgt+0xff8>

So I did this (the .s is obtained by objdump -d vmlinux.gold >gold.s)
sed -re 's/(# |0x)[a-z0-9]+/HEX/g' gold.s | colrm 1 47 >gold1.s

And diff those.

Then aside from some local symbol name differences:
-       cmp    HEX(%rip),%edx        HEX <.LC3>
+       cmp    HEX(%rip),%edx        HEX <kallsyms_token_index+HEX>

I have this diff (+ is bfd), which is coming from .notes (why does 
objdump think it needs to dump .notes as assembly though?):
+       add    $HEX,%al
+       add    %al,(%rax)
+       adc    $HEX,%al
+       add    %al,(%rax)
+       add    (%rax),%eax
+       add    %al,(%rax)
+       rex.RXB
+       rex.WRX push   %rbp
+       add    %dh,%bh
+       insb   (%dx),%es:(%rdi)
+       jle    ffffffff813d1250 <bad_to_user+HEX>
+       and    $HEX,%dl
+       (bad)
+       jge    ffffffff813d1331 <__start___ex_table+HEX>
+       cs
+       callq  ffffffff2bbe8fc1 <__crc___pskb_pull_tail+HEX>
+       stc
+       mov    $HEX,%ch
+       (bad)


>
>> ... there is also difference in padding:
>> gold uses 00 00 90 90 (add %al, (%rax) nop nop), while BFD uses 90 90 90
>> 90 (4 nops).
>
> That is a dispute over interpretation of the linker script:
> } :text=0x9090
> The original spec was from the days when 2==sizeof(int), so padding was
> a 16-bit value, thus 0x9090 was all that mattered. Check the spec
> for an update regarding width of padding. In the meantime, try changing
> the script to
> } :text=0x90909090
> which should remove this source of differences.

Yes that removes the differences from the nops.

>
>> If I read that correctly it means it uses hardware pages with a pagesize
>> of 2MB for kernel text.
>
> Yes.
>
>> Since gold aligns only to 0x1000 perhaps the rodata ends up in the same
>> hardware page as the .text.
>>
>> I think these are the relevant align commands from the vmlinux.lds ...
>
>> . = ALIGN((1 << 21));
>
> It is a bug that gold does not propagate that alignment constraint
> to the .p_align.
>
>> If the hw pagesize is 2MB, then its not divisible, so its a bug.
>> Should I open a bugreport, or are there some patches to gold that I
>> could try?
>
> Definitely open a bug report about ". = ALIGN((1 << 21));"

Opened bug 11490.

>
>> I think the .note difference is just due to gold embedding its version:
>> -Note section [ 2] '.notes' of 60 bytes at offset 0x3d2c58:
>> +Note section [ 2] '.notes' of 36 bytes at offset 0x5d1c58:
>> Owner Data size Type
>> - GNU 8 GNU_GOLD_VERSION
>> - Linker version: gold 1.9
>> GNU 20 GNU_BUILD_ID
>> - Build ID: a865af685f5222cdc17a28ea4e49d58b2185bc05
>> + Build ID: 07b53da4e169ad1079080043ad72384fb80d0ea3
>
> Again, it would be comforting to make a test run with GNU_GOLD_VERSION
> omitted, to see if the .text becomes identical (except for Build ID)
> with ld.
>

I did that (by editing gold source and returning from 
create_gold_note()), but as I've shown above there are still diffs due 
to global addresses...

Best regards,
--Edwin

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[John Reiser]

> I still have differences:
> -ffffffff810000e1: 48 01 2d 08 c0 46 00 add %rbp,0x46c008(%rip) # ffffffff8146c0f0 <trampoline_level4_pgt>
> -ffffffff810000e8: 48 01 2d f9 cf 46 00 add %rbp,0x46cff9(%rip) # ffffffff8146d0e8 <trampoline_level4_pgt+0xff8>
> +ffffffff810000e1: 48 01 2d 98 74 40 00 add %rbp,0x407498(%rip) # ffffffff81407580 <trampoline_level4_pgt>
> +ffffffff810000e8: 48 01 2d 89 84 40 00 add %rbp,0x408489(%rip) # ffffffff81408578 <trampoline_level4_pgt+0xff8>

Please try generating and diff'ing a linker map.  This should help
identify the changes in symbol addresses.  In particular, the change
with the lowest (or highest) address often gives a clue.  Use the
'-M' or '--print-map' parameter to generate the map on stdout,
or the '-Map=filename' parameter ("-Map=gold.map") to go directly
to a file.

> I have this diff (+ is bfd), which is coming from .notes ...

Presumably that part of the diff goes away when GNU_GOLD_VERSION
is deleted from the NOTES.

-- 

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Ian Lance Taylor]

John Reiser <jreiser@bitwagon.com> writes:

> The differing .p_align values of 0x1000 vs 0x200000 indicate that
> gold has a bug interpreting the commands from the linker script
> for alignment of Elf64_Phdr.

It is perhaps worth noting that for x86_64 gold by default uses -z
max-page-size 0x1000 whereas the default for GNU ld is -z
max-page-size 0x200000.  While I haven't looked at the Linux linker
script, perhaps it is assuming the latter.

Ian

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[H.J. Lu]

On Mon, Apr 12, 2010 at 10:27 PM, Ian Lance Taylor <iant@google.com> wrote:
> John Reiser <jreiser@bitwagon.com> writes:
>
>> The differing .p_align values of 0x1000 vs 0x200000 indicate that
>> gold has a bug interpreting the commands from the linker script
>> for alignment of Elf64_Phdr.
>
> It is perhaps worth noting that for x86_64 gold by default uses -z
> max-page-size 0x1000 whereas the default for GNU ld is -z
> max-page-size 0x200000.  While I haven't looked at the Linux linker
> script, perhaps it is assuming the latter.
>

Linux kernel linker scripts needs to align .rodata section to 2MB:

. = ALIGN((1 << 21));

Since gold can only align to 4K, gold can't be used on Linux
kernel.


-- 
H.J.

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[H.J. Lu]

On Thu, Apr 22, 2010 at 2:10 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Apr 12, 2010 at 10:27 PM, Ian Lance Taylor <iant@google.com> wrote:
>> John Reiser <jreiser@bitwagon.com> writes:
>>
>>> The differing .p_align values of 0x1000 vs 0x200000 indicate that
>>> gold has a bug interpreting the commands from the linker script
>>> for alignment of Elf64_Phdr.
>>
>> It is perhaps worth noting that for x86_64 gold by default uses -z
>> max-page-size 0x1000 whereas the default for GNU ld is -z
>> max-page-size 0x200000.  While I haven't looked at the Linux linker
>> script, perhaps it is assuming the latter.
>>
>
> Linux kernel linker scripts needs to align .rodata section to 2MB:
>
> . = ALIGN((1 << 21));
>
> Since gold can only align to 4K, gold can't be used on Linux
> kernel.
>

Hi Ian,

If gold should be compatible with ld, this patch should be applied.


-- 
H.J.
---
diff --git a/gold/x86_64.cc b/gold/x86_64.cc
index 9110278..99be4de 100644
--- a/gold/x86_64.cc
+++ b/gold/x86_64.cc
@@ -516,7 +516,7 @@ const Target::Target_info Target_x86_64::x86_64_info =
   '\0',       // wrap_char
   "/lib/ld64.so.1",     // program interpreter
   0x400000,      // default_text_segment_address
-  0x1000,     // abi_pagesize (overridable by -z max-page-size)
+  0x200000,      // abi_pagesize (overridable by -z max-page-size)
   0x1000,     // common_pagesize (overridable by -z common-page-size)
   elfcpp::SHN_UNDEF,   // small_common_shndx
   elfcpp::SHN_X86_64_LCOMMON,   // large_common_shndx

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Suresh Siddha]

On Thu, 2010-04-22 at 14:21 -0700, H.J. Lu wrote:
> On Thu, Apr 22, 2010 at 2:10 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> > On Mon, Apr 12, 2010 at 10:27 PM, Ian Lance Taylor <iant@google.com>
> wrote:
> >> John Reiser <jreiser@bitwagon.com> writes:
> >>
> >>> The differing .p_align values of 0x1000 vs 0x200000 indicate that
> >>> gold has a bug interpreting the commands from the linker script
> >>> for alignment of Elf64_Phdr.
> >>
> >> It is perhaps worth noting that for x86_64 gold by default uses -z
> >> max-page-size 0x1000 whereas the default for GNU ld is -z
> >> max-page-size 0x200000.  While I haven't looked at the Linux linker
> >> script, perhaps it is assuming the latter.
> >>
> >
> > Linux kernel linker scripts needs to align .rodata section to 2MB:
> >
> > . = ALIGN((1 << 21));
> >
> > Since gold can only align to 4K, gold can't be used on Linux
> > kernel.
> >
> 
> Hi Ian,
> 
> If gold should be compatible with ld, this patch should be applied.
> 

We can also workaround in the kernel by overriding the value with "-z
max-page-size=0x200000" if this is supported.

thanks,
suresh

> 
> -- 
> H.J.
> ---
> diff --git a/gold/x86_64.cc b/gold/x86_64.cc
> index 9110278..99be4de 100644
> --- a/gold/x86_64.cc
> +++ b/gold/x86_64.cc
> @@ -516,7 +516,7 @@ const Target::Target_info
> Target_x86_64::x86_64_info =
>    '\0',       // wrap_char
>    "/lib/ld64.so.1",     // program interpreter
>    0x400000,      // default_text_segment_address
> -  0x1000,     // abi_pagesize (overridable by -z max-page-size)
> +  0x200000,      // abi_pagesize (overridable by -z max-page-size)
>    0x1000,     // common_pagesize (overridable by -z common-page-size)
>    elfcpp::SHN_UNDEF,   // small_common_shndx
>    elfcpp::SHN_X86_64_LCOMMON,   // large_common_shndx

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Ian Lance Taylor]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> If gold should be compatible with ld, this patch should be applied.
>
>
> -- 
> H.J.
> ---
> diff --git a/gold/x86_64.cc b/gold/x86_64.cc
> index 9110278..99be4de 100644
> --- a/gold/x86_64.cc
> +++ b/gold/x86_64.cc
> @@ -516,7 +516,7 @@ const Target::Target_info Target_x86_64::x86_64_info =
>    '\0',       // wrap_char
>    "/lib/ld64.so.1",     // program interpreter
>    0x400000,      // default_text_segment_address
> -  0x1000,     // abi_pagesize (overridable by -z max-page-size)
> +  0x200000,      // abi_pagesize (overridable by -z max-page-size)
>    0x1000,     // common_pagesize (overridable by -z common-page-size)
>    elfcpp::SHN_UNDEF,   // small_common_shndx
>    elfcpp::SHN_X86_64_LCOMMON,   // large_common_shndx


That patch incurs a cost for every x86_64 executable and shared
library by making them larger and making them use much more address
space than they really require.  At present there are very few
programs which need a large page size.  I would prefer to encourage
them to use the -z max-page-size option if at all possible.

Ian

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[H.J. Lu]

On Thu, Apr 22, 2010 at 5:00 PM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> If gold should be compatible with ld, this patch should be applied.
>>
>>
>> --
>> H.J.
>> ---
>> diff --git a/gold/x86_64.cc b/gold/x86_64.cc
>> index 9110278..99be4de 100644
>> --- a/gold/x86_64.cc
>> +++ b/gold/x86_64.cc
>> @@ -516,7 +516,7 @@ const Target::Target_info Target_x86_64::x86_64_info =
>>    '\0',       // wrap_char
>>    "/lib/ld64.so.1",     // program interpreter
>>    0x400000,      // default_text_segment_address
>> -  0x1000,     // abi_pagesize (overridable by -z max-page-size)
>> +  0x200000,      // abi_pagesize (overridable by -z max-page-size)
>>    0x1000,     // common_pagesize (overridable by -z common-page-size)
>>    elfcpp::SHN_UNDEF,   // small_common_shndx
>>    elfcpp::SHN_X86_64_LCOMMON,   // large_common_shndx
>
>
> That patch incurs a cost for every x86_64 executable and shared
> library by making them larger and making them use much more address
> space than they really require.  At present there are very few
> programs which need a large page size.  I would prefer to encourage
> them to use the -z max-page-size option if at all possible.
>

2MB maximum page size may have a bigger gap between PT_LOAD
segment in memory than 4KB maximum page size. But it doesn't necessarily
use more memory nor disk space. Since x86_64 is 64bit, address
space shouldn't be an issue in vast majority cases. I'd like to hear
a case to say otherwise.

Thanks.

-- 
H.J.

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Ian Lance Taylor]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> 2MB maximum page size may have a bigger gap between PT_LOAD
> segment in memory than 4KB maximum page size. But it doesn't necessarily
> use more memory nor disk space. Since x86_64 is 64bit, address
> space shouldn't be an issue in vast majority cases. I'd like to hear
> a case to say otherwise.

The increased use of address space was an issue with x86_64 binaries
which opened hundreds of shared libraries.  Each shared library was
burning 2 megabytes of address space between the text and data
segments.  This in turn caused trouble with setting limits on the
amount of virtual memory which could be allocated: greatly increasing
the limits to permit hundreds of shared libraries meant that the
limits were unreasonably high for programs with only a couple of
shared libraries.  This was a problem we found with GNU ld a while
back.  While other workarounds were possible, using -z max-page-size
was a simple one.  I didn't see any reason to carry that problem
forward with gold, given that extremely few programs need -z
max-page-size larger than 0x1000 on x86_64.

Ian

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[H.J. Lu]

On Thu, Apr 22, 2010 at 6:21 PM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> 2MB maximum page size may have a bigger gap between PT_LOAD
>> segment in memory than 4KB maximum page size. But it doesn't necessarily
>> use more memory nor disk space. Since x86_64 is 64bit, address
>> space shouldn't be an issue in vast majority cases. I'd like to hear
>> a case to say otherwise.
>
> The increased use of address space was an issue with x86_64 binaries
> which opened hundreds of shared libraries.  Each shared library was
> burning 2 megabytes of address space between the text and data
> segments.  This in turn caused trouble with setting limits on the
> amount of virtual memory which could be allocated: greatly increasing
> the limits to permit hundreds of shared libraries meant that the
> limits were unreasonably high for programs with only a couple of
> shared libraries.  This was a problem we found with GNU ld a while
> back.  While other workarounds were possible, using -z max-page-size
> was a simple one.  I didn't see any reason to carry that problem
> forward with gold, given that extremely few programs need -z
> max-page-size larger than 0x1000 on x86_64.

So the issue is you want to use hundreds of shared libraries
and limit the virtual memory size. This is very unique to your
organization. Otherwise, we will hear many complaints over
the last few years.

The idea of 2MB maximum page size is we may use variable
page size one day without recompiling everything.


-- 
H.J.

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[David Miller]

From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Thu, 22 Apr 2010 18:46:14 -0700

> The idea of 2MB maximum page size is we may use variable
> page size one day without recompiling everything.

Indeed.

Because it's 64k on sparc (even 32-bit) I was at least able to
experiment with such things.

In fact doesn't the x86_64 specification explicitly state that the
default maximum page size is to be 2MB in ELF objects?

Finally, I really don't personally buy the argument that the 64-bit
address space will be seriously taken close to exhaustion due to a 2MB
maximum page size, even with hundreds of shared libraries.  We have
2^32 times (or a similar order of magnitude) more address space
available than on 32-bit.

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[H.J. Lu]

On Thu, Apr 22, 2010 at 6:58 PM, David Miller <davem@davemloft.net> wrote:
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Date: Thu, 22 Apr 2010 18:46:14 -0700
>
>> The idea of 2MB maximum page size is we may use variable
>> page size one day without recompiling everything.
>
> Indeed.
>
> Because it's 64k on sparc (even 32-bit) I was at least able to
> experiment with such things.

It is very unfortunate that binaries created by gold can't take
advantage of variable page size.

> In fact doesn't the x86_64 specification explicitly state that the
> default maximum page size is to be 2MB in ELF objects?

I saw

--
3.3.3 Page Size
Systems are permitted to use any power-of-two page size between 4KB and 64KB,
inclusive
--

in x86-64 psABI.

> Finally, I really don't personally buy the argument that the 64-bit
> address space will be seriously taken close to exhaustion due to a 2MB
> maximum page size, even with hundreds of shared libraries.  We have
> 2^32 times (or a similar order of magnitude) more address space
> available than on 32-bit.
>

Ian's issue is they want to limit the size of virtual memory:

cputime         unlimited
filesize        unlimited
datasize        unlimited
stacksize       8MB
coredumpsize    0kB
memoryuse       unlimited
maxproc         30985
descriptors     1024
memorylocked    64kB
addressspace    unlimited
maxfilelocks    unlimited
sigpending      30985
msgqueue        819200
nice            0
rt_priority     0

Personally I think they can set memory size limit on a per-process/login/binary
basis via other tools, like pam, without using 4K page size on x86-64.
Gold and ld should use the same maximum page size on x86-64.

-- 
H.J.

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Ian Lance Taylor]

David Miller <davem@davemloft.net> writes:

> In fact doesn't the x86_64 specification explicitly state that the
> default maximum page size is to be 2MB in ELF objects?

No, it says "Systems are permitted to use any power-of-two page size
between 4KB and 64KB, inclusive."

Ian

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[H.J. Lu]

On Thu, Apr 22, 2010 at 8:05 PM, Ian Lance Taylor <iant@google.com> wrote:
> David Miller <davem@davemloft.net> writes:
>
>> In fact doesn't the x86_64 specification explicitly state that the
>> default maximum page size is to be 2MB in ELF objects?
>
> No, it says "Systems are permitted to use any power-of-two page size
> between 4KB and 64KB, inclusive."
>

What are "Systems" here? Gold? There is no way for any OS to
load a binary created by the default gold with 8K, 16K, 32K,
64K page sizes.

With ld, OS can use different page sizes up to 2MB.

-- 
H.J.

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[John Reiser]

On 04/22/2010 02:10 PM, H.J. Lu wrote:
> On Mon, Apr 12, 2010 at 10:27 PM, Ian Lance Taylor<iant@google.com>  wrote:
>> John Reiser<jreiser@bitwagon.com>  writes:
>>
>>> The differing .p_align values of 0x1000 vs 0x200000 indicate that
>>> gold has a bug interpreting the commands from the linker script
>>> for alignment of Elf64_Phdr.
>>
>> It is perhaps worth noting that for x86_64 gold by default uses -z
>> max-page-size 0x1000 whereas the default for GNU ld is -z
>> max-page-size 0x200000.  While I haven't looked at the Linux linker
>> script, perhaps it is assuming the latter.
>>
>
> Linux kernel linker scripts needs to align .rodata section to 2MB:
>
> . = ALIGN((1<<  21));
>
> Since gold can only align to 4K, gold can't be used on Linux
> kernel.

The linker script statement ". = ALIGN((1<<  21));" requires alignment
to 2 MiB.  If gold "can only align to 4 KiB", then gold must emit an
error message upon processing input that requires a larger alignment.
It is a bug that current gold does not emit such a message for this case.

It seems strange to me that "gold by default uses -z max-page-size 0x1000"
implies "gold cannot align to anything more than 0x1000".  At the minimum,
specifying "-z max-page-size 0x200000" ought to be a workaround here.

-- 

gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[Ian Lance Taylor]

[-- Attachment #1: Type: text/plain, Size: 2413 bytes --]

John Reiser <jreiser@bitwagon.com> writes:

>> Linux kernel linker scripts needs to align .rodata section to 2MB:
>>
>> . = ALIGN((1<<  21));
>>
>> Since gold can only align to 4K, gold can't be used on Linux
>> kernel.
>
> The linker script statement ". = ALIGN((1<<  21));" requires alignment
> to 2 MiB.  If gold "can only align to 4 KiB", then gold must emit an
> error message upon processing input that requires a larger alignment.
> It is a bug that current gold does not emit such a message for this case.

The problem is that the alignment requested by the linker script is
not reflected in the linker output.  That actually appears to be true
of the GNU linker as well.  Logically, an alignment requested in the
linker script should be reflected in the program segments.

I committed this patch to make an alignment requested in the linker
script be reflected in the p_align field of the generated program
headers.  I don't know if this actually fixes the problem, but it
seems like the right thing to do.

Ian


2010-04-22  Ian Lance Taylor  <iant@google.com>

	* expression.cc (Expression::Expression_eval_info): Add
	result_alignment_pointer field.
	(Expression::eval_with_dot): Add result_alignment_pointer
	parameter.  Change all callers.
	(Expression::eval_maybe_dot): Likewise.
	(class Binary_expression): Add alignment_pointer parameter to
	left_value and right_value.  Change all callers.
	(BINARY_EXPRESSION): Set result alignment.
	(class Trinary_expression): Add alignment_pointer parameter to
	arg2_value and arg3_value.  Change all callers.
	(Trinary_cond::value): Set result alignment.
	(Max_expression::value, Min_expression::value): Likewise.
	(Align_expression::value): Likewise.
	* script-sections.cc (class Sections_element): Add dot_alignment
	parameter to set_section_addresses virtual function.  Update
	instantiations.
	(class Output_section_element): Likewise.
	(Script_sections::create_segments): Add dot_alignment parameter.
	Change all callers.
	(Script_sections::create_segments_from_phdrs_clause): Likewise.
	(Script_sections::set_phdrs_clause_addresses): Likewise.
	* script-sections.h: Update declarations.
	* script.h: Update declarations.
	* output.h (Output_segment::set_minimum_p_align): Don't decrease
	min_p_align.
	* testsuite/script_test_3.t: Set large alignment.
	* testsuite/script_test_3.sh: Make sure that at least one LOAD
	segment has expected alignment.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: align --]
[-- Type: text/x-diff, Size: 28992 bytes --]

Index: expression.cc
===================================================================
RCS file: /cvs/src/src/gold/expression.cc,v
retrieving revision 1.13
diff -p -u -r1.13 expression.cc
--- expression.cc	14 Dec 2009 19:53:04 -0000	1.13
+++ expression.cc	23 Apr 2010 04:37:09 -0000
@@ -66,6 +66,8 @@ struct Expression::Expression_eval_info
   Output_section* dot_section;
   // Points to where the section of the result should be stored.
   Output_section** result_section_pointer;
+  // Pointer to where the alignment of the result should be stored.
+  uint64_t* result_alignment_pointer;
 };
 
 // Evaluate an expression.
@@ -76,7 +78,7 @@ Expression::eval(const Symbol_table* sym
 {
   Output_section* dummy;
   return this->eval_maybe_dot(symtab, layout, check_assertions,
-			      false, 0, NULL, &dummy);
+			      false, 0, NULL, &dummy, NULL);
 }
 
 // Evaluate an expression which may refer to the dot symbol.
@@ -85,10 +87,12 @@ uint64_t
 Expression::eval_with_dot(const Symbol_table* symtab, const Layout* layout,
 			  bool check_assertions, uint64_t dot_value,
 			  Output_section* dot_section,
-			  Output_section** result_section_pointer)
+			  Output_section** result_section_pointer,
+			  uint64_t* result_alignment_pointer)
 {
   return this->eval_maybe_dot(symtab, layout, check_assertions, true,
-			      dot_value, dot_section, result_section_pointer);
+			      dot_value, dot_section, result_section_pointer,
+			      result_alignment_pointer);
 }
 
 // Evaluate an expression which may or may not refer to the dot
@@ -98,7 +102,8 @@ uint64_t
 Expression::eval_maybe_dot(const Symbol_table* symtab, const Layout* layout,
 			   bool check_assertions, bool is_dot_available,
 			   uint64_t dot_value, Output_section* dot_section,
-			   Output_section** result_section_pointer)
+			   Output_section** result_section_pointer,
+			   uint64_t* result_alignment_pointer)
 {
   Expression_eval_info eei;
   eei.symtab = symtab;
@@ -113,6 +118,8 @@ Expression::eval_maybe_dot(const Symbol_
   *result_section_pointer = NULL;
   eei.result_section_pointer = result_section_pointer;
 
+  eei.result_alignment_pointer = result_alignment_pointer;
+
   return this->value(&eei);
 }
 
@@ -247,7 +254,8 @@ class Unary_expression : public Expressi
 				      eei->is_dot_available,
 				      eei->dot_value,
 				      eei->dot_section,
-				      arg_section_pointer);
+				      arg_section_pointer,
+				      eei->result_alignment_pointer);
   }
 
   void
@@ -317,26 +325,30 @@ class Binary_expression : public Express
  protected:
   uint64_t
   left_value(const Expression_eval_info* eei,
-	     Output_section** section_pointer) const
+	     Output_section** section_pointer,
+	     uint64_t* alignment_pointer) const
   {
     return this->left_->eval_maybe_dot(eei->symtab, eei->layout,
 				       eei->check_assertions,
 				       eei->is_dot_available,
 				       eei->dot_value,
 				       eei->dot_section,
-				       section_pointer);
+				       section_pointer,
+				       alignment_pointer);
   }
 
   uint64_t
   right_value(const Expression_eval_info* eei,
-	      Output_section** section_pointer) const
+	      Output_section** section_pointer,
+	      uint64_t* alignment_pointer) const
   {
     return this->right_->eval_maybe_dot(eei->symtab, eei->layout,
 					eei->check_assertions,
 					eei->is_dot_available,
 					eei->dot_value,
 					eei->dot_section,
-					section_pointer);
+					section_pointer,
+					alignment_pointer);
   }
 
   void
@@ -385,15 +397,27 @@ class Binary_expression : public Express
     value(const Expression_eval_info* eei)				\
     {									\
       Output_section* left_section;					\
-      uint64_t left = this->left_value(eei, &left_section);		\
+      uint64_t left_alignment;						\
+      uint64_t left = this->left_value(eei, &left_section,		\
+				       &left_alignment);		\
       Output_section* right_section;					\
-      uint64_t right = this->right_value(eei, &right_section);		\
+      uint64_t right_alignment;						\
+      uint64_t right = this->right_value(eei, &right_section,		\
+					 &right_alignment);		\
       if (KEEP_RIGHT && left_section == NULL && right_section != NULL)	\
-	*eei->result_section_pointer = right_section;			\
+	{								\
+	  *eei->result_section_pointer = right_section;			\
+	  if (eei->result_alignment_pointer != NULL)			\
+	    *eei->result_alignment_pointer = right_alignment;		\
+	}								\
       else if (KEEP_LEFT						\
 	       && left_section != NULL					\
 	       && right_section == NULL)				\
-	*eei->result_section_pointer = left_section;			\
+	{								\
+	  *eei->result_section_pointer = left_section;			\
+	  if (eei->result_alignment_pointer != NULL)			\
+	    *eei->result_alignment_pointer = right_alignment;		\
+	}								\
       else if ((WARN || left_section != right_section)			\
 	       && (left_section != NULL || right_section != NULL)	\
 	       && parameters->options().relocatable())			\
@@ -469,31 +493,36 @@ class Trinary_expression : public Expres
 				       eei->is_dot_available,
 				       eei->dot_value,
 				       eei->dot_section,
-				       section_pointer);
+				       section_pointer,
+				       NULL);
   }
 
   uint64_t
   arg2_value(const Expression_eval_info* eei,
-	     Output_section** section_pointer) const
+	     Output_section** section_pointer,
+	     uint64_t* alignment_pointer) const
   {
     return this->arg1_->eval_maybe_dot(eei->symtab, eei->layout,
 				       eei->check_assertions,
 				       eei->is_dot_available,
 				       eei->dot_value,
 				       eei->dot_section,
-				       section_pointer);
+				       section_pointer,
+				       alignment_pointer);
   }
 
   uint64_t
   arg3_value(const Expression_eval_info* eei,
-	     Output_section** section_pointer) const
+	     Output_section** section_pointer,
+	     uint64_t* alignment_pointer) const
   {
     return this->arg1_->eval_maybe_dot(eei->symtab, eei->layout,
 				       eei->check_assertions,
 				       eei->is_dot_available,
 				       eei->dot_value,
 				       eei->dot_section,
-				       section_pointer);
+				       section_pointer,
+				       alignment_pointer);
   }
 
   void
@@ -529,8 +558,10 @@ class Trinary_cond : public Trinary_expr
     Output_section* arg1_section;
     uint64_t arg1 = this->arg1_value(eei, &arg1_section);
     return (arg1
-	    ? this->arg2_value(eei, eei->result_section_pointer)
-	    : this->arg3_value(eei, eei->result_section_pointer));
+	    ? this->arg2_value(eei, eei->result_section_pointer,
+			       eei->result_alignment_pointer)
+	    : this->arg3_value(eei, eei->result_section_pointer,
+			       eei->result_alignment_pointer));
   }
 
   void
@@ -565,14 +596,27 @@ class Max_expression : public Binary_exp
   value(const Expression_eval_info* eei)
   {
     Output_section* left_section;
-    uint64_t left = this->left_value(eei, &left_section);
+    uint64_t left_alignment;
+    uint64_t left = this->left_value(eei, &left_section, &left_alignment);
     Output_section* right_section;
-    uint64_t right = this->right_value(eei, &right_section);
+    uint64_t right_alignment;
+    uint64_t right = this->right_value(eei, &right_section, &right_alignment);
     if (left_section == right_section)
       *eei->result_section_pointer = left_section;
     else if ((left_section != NULL || right_section != NULL)
 	     && parameters->options().relocatable())
       gold_warning(_("max applied to section relative value"));
+    if (eei->result_alignment_pointer != NULL)
+      {
+	uint64_t ra = *eei->result_alignment_pointer;
+	if (left > right)
+	  ra = std::max(ra, left_alignment);
+	else if (right > left)
+	  ra = std::max(ra, right_alignment);
+	else
+	  ra = std::max(ra, std::max(left_alignment, right_alignment));
+	*eei->result_alignment_pointer = ra;
+      }
     return std::max(left, right);
   }
 
@@ -600,14 +644,27 @@ class Min_expression : public Binary_exp
   value(const Expression_eval_info* eei)
   {
     Output_section* left_section;
-    uint64_t left = this->left_value(eei, &left_section);
+    uint64_t left_alignment;
+    uint64_t left = this->left_value(eei, &left_section, &left_alignment);
     Output_section* right_section;
-    uint64_t right = this->right_value(eei, &right_section);
+    uint64_t right_alignment;
+    uint64_t right = this->right_value(eei, &right_section, &right_alignment);
     if (left_section == right_section)
       *eei->result_section_pointer = left_section;
     else if ((left_section != NULL || right_section != NULL)
 	     && parameters->options().relocatable())
       gold_warning(_("min applied to section relative value"));
+    if (eei->result_alignment_pointer != NULL)
+      {
+	uint64_t ra = *eei->result_alignment_pointer;
+	if (left < right)
+	  ra = std::max(ra, left_alignment);
+	else if (right < left)
+	  ra = std::max(ra, right_alignment);
+	else
+	  ra = std::max(ra, std::max(left_alignment, right_alignment));
+	*eei->result_alignment_pointer = ra;
+      }
     return std::min(left, right);
   }
 
@@ -734,12 +791,21 @@ class Align_expression : public Binary_e
   value(const Expression_eval_info* eei)
   {
     Output_section* align_section;
-    uint64_t align = this->right_value(eei, &align_section);
+    uint64_t align = this->right_value(eei, &align_section, NULL);
     if (align_section != NULL
 	&& parameters->options().relocatable())
       gold_warning(_("aligning to section relative value"));
 
-    uint64_t value = this->left_value(eei, eei->result_section_pointer);
+    if (eei->result_alignment_pointer != NULL
+	&& align > *eei->result_alignment_pointer)
+      {
+	uint64_t a = align;
+	while ((a & (a - 1)) != 0)
+	  a &= a - 1;
+	*eei->result_alignment_pointer = a;
+      }
+
+    uint64_t value = this->left_value(eei, eei->result_section_pointer, NULL);
     if (align <= 1)
       return value;
     return ((value + align - 1) / align) * align;
Index: output.h
===================================================================
RCS file: /cvs/src/src/gold/output.h,v
retrieving revision 1.103
diff -p -u -r1.103 output.h
--- output.h	9 Apr 2010 17:32:58 -0000	1.103
+++ output.h	23 Apr 2010 04:37:10 -0000
@@ -3833,7 +3833,10 @@ class Output_segment
   // upward based on the section alignments.
   void
   set_minimum_p_align(uint64_t align)
-  { this->min_p_align_ = align; }
+  {
+    if (align > this->min_p_align_)
+      this->min_p_align_ = align;
+  }
 
   // Set the offset of this segment based on the section.  This should
   // only be called for a non-PT_LOAD segment.
Index: script-sections.cc
===================================================================
RCS file: /cvs/src/src/gold/script-sections.cc,v
retrieving revision 1.32
diff -p -u -r1.32 script-sections.cc
--- script-sections.cc	9 Apr 2010 17:32:58 -0000	1.32
+++ script-sections.cc	23 Apr 2010 04:37:11 -0000
@@ -369,7 +369,8 @@ class Sections_element
   // Set section addresses.  This includes applying assignments if the
   // the expression is an absolute value.
   virtual void
-  set_section_addresses(Symbol_table*, Layout*, uint64_t*, uint64_t*)
+  set_section_addresses(Symbol_table*, Layout*, uint64_t*, uint64_t*,
+			uint64_t*)
   { }
 
   // Check a constraint (ONLY_IF_RO, etc.) on an output section.  If
@@ -447,7 +448,7 @@ class Sections_element_assignment : publ
   // absolute symbols when setting dot.
   void
   set_section_addresses(Symbol_table* symtab, Layout* layout,
-			uint64_t* dot_value, uint64_t*)
+			uint64_t* dot_value, uint64_t*, uint64_t*)
   {
     this->assignment_.set_if_absolute(symtab, layout, true, *dot_value);
   }
@@ -484,17 +485,18 @@ class Sections_element_dot_assignment : 
     // to be absolute.
     Output_section* dummy;
     *dot_value = this->val_->eval_with_dot(symtab, layout, true, *dot_value,
-					   NULL, &dummy);
+					   NULL, &dummy, NULL);
   }
 
   // Update the dot symbol while setting section addresses.
   void
   set_section_addresses(Symbol_table* symtab, Layout* layout,
-			uint64_t* dot_value, uint64_t* load_address)
+			uint64_t* dot_value, uint64_t* dot_alignment,
+			uint64_t* load_address)
   {
     Output_section* dummy;
     *dot_value = this->val_->eval_with_dot(symtab, layout, false, *dot_value,
-					   NULL, &dummy);
+					   NULL, &dummy, dot_alignment);
     *load_address = *dot_value;
   }
 
@@ -577,7 +579,7 @@ class Output_section_element
   // the expression is an absolute value.
   virtual void
   set_section_addresses(Symbol_table*, Layout*, Output_section*, uint64_t,
-			uint64_t*, Output_section**, std::string*,
+			uint64_t*, uint64_t*, Output_section**, std::string*,
 			Input_section_list*)
   { }
 
@@ -635,8 +637,8 @@ class Output_section_element_assignment 
   // absolute symbols when setting dot.
   void
   set_section_addresses(Symbol_table* symtab, Layout* layout, Output_section*,
-			uint64_t, uint64_t* dot_value, Output_section**,
-			std::string*, Input_section_list*)
+			uint64_t, uint64_t* dot_value, uint64_t*,
+			Output_section**, std::string*, Input_section_list*)
   {
     this->assignment_.set_if_absolute(symtab, layout, true, *dot_value);
   }
@@ -668,14 +670,14 @@ class Output_section_element_dot_assignm
 		   uint64_t* dot_value, Output_section** dot_section)
   {
     *dot_value = this->val_->eval_with_dot(symtab, layout, true, *dot_value,
-					   *dot_section, dot_section);
+					   *dot_section, dot_section, NULL);
   }
 
   // Update the dot symbol while setting section addresses.
   void
   set_section_addresses(Symbol_table* symtab, Layout* layout, Output_section*,
-			uint64_t, uint64_t* dot_value, Output_section**,
-			std::string*, Input_section_list*);
+			uint64_t, uint64_t* dot_value, uint64_t*,
+			Output_section**, std::string*, Input_section_list*);
 
   // Print for debugging.
   void
@@ -699,13 +701,14 @@ Output_section_element_dot_assignment::s
     Output_section* output_section,
     uint64_t,
     uint64_t* dot_value,
+    uint64_t* dot_alignment,
     Output_section** dot_section,
     std::string* fill,
     Input_section_list*)
 {
   uint64_t next_dot = this->val_->eval_with_dot(symtab, layout, false,
 						*dot_value, *dot_section,
-						dot_section);
+						dot_section, dot_alignment);
   if (next_dot < *dot_value)
     gold_error(_("dot may not move backward"));
   if (next_dot > *dot_value && output_section != NULL)
@@ -807,7 +810,7 @@ Output_data_expression::do_write_to_buff
   Output_section* dummy;
   uint64_t val = this->val_->eval_with_dot(this->symtab_, this->layout_,
 					   true, this->dot_value_,
-					   this->dot_section_, &dummy);
+					   this->dot_section_, &dummy, NULL);
 
   if (parameters->target().is_big_endian())
     this->endian_write_to_buffer<true>(val, buf);
@@ -868,8 +871,8 @@ class Output_section_element_data : publ
   // Store the value in the section.
   void
   set_section_addresses(Symbol_table*, Layout*, Output_section*, uint64_t,
-			uint64_t* dot_value, Output_section**, std::string*,
-			Input_section_list*);
+			uint64_t* dot_value, uint64_t*, Output_section**,
+			std::string*, Input_section_list*);
 
   // Print for debugging.
   void
@@ -893,6 +896,7 @@ Output_section_element_data::set_section
     Output_section* os,
     uint64_t,
     uint64_t* dot_value,
+    uint64_t*,
     Output_section** dot_section,
     std::string*,
     Input_section_list*)
@@ -949,14 +953,14 @@ class Output_section_element_fill : publ
   // Update the fill value while setting section addresses.
   void
   set_section_addresses(Symbol_table* symtab, Layout* layout, Output_section*,
-			uint64_t, uint64_t* dot_value,
+			uint64_t, uint64_t* dot_value, uint64_t*,
 			Output_section** dot_section,
 			std::string* fill, Input_section_list*)
   {
     Output_section* fill_section;
     uint64_t fill_val = this->val_->eval_with_dot(symtab, layout, false,
 						  *dot_value, *dot_section,
-						  &fill_section);
+						  &fill_section, NULL);
     if (fill_section != NULL)
       gold_warning(_("fill value is not absolute"));
     // FIXME: The GNU linker supports fill values of arbitrary length.
@@ -1012,7 +1016,7 @@ class Output_section_element_input : pub
   // Set the section address.
   void
   set_section_addresses(Symbol_table* symtab, Layout* layout, Output_section*,
-			uint64_t subalign, uint64_t* dot_value,
+			uint64_t subalign, uint64_t* dot_value, uint64_t*,
 			Output_section**, std::string* fill,
 			Input_section_list*);
 
@@ -1309,6 +1313,7 @@ Output_section_element_input::set_sectio
     Output_section* output_section,
     uint64_t subalign,
     uint64_t* dot_value,
+    uint64_t*,
     Output_section** dot_section,
     std::string* fill,
     Input_section_list* input_sections)
@@ -1629,7 +1634,8 @@ class Output_section_definition : public
   // Set the section address.
   void
   set_section_addresses(Symbol_table* symtab, Layout* layout,
-			uint64_t* dot_value, uint64_t* load_address);
+			uint64_t* dot_value, uint64_t*,
+			uint64_t* load_address);
 
   // Check a constraint (ONLY_IF_RO, etc.) on an output section.  If
   // this section is constrained, and the input sections do not match,
@@ -1861,7 +1867,7 @@ Output_section_definition::finalize_symb
 	  Output_section* dummy;
 	  address = this->address_->eval_with_dot(symtab, layout, true,
 						  *dot_value, NULL,
-						  &dummy);
+						  &dummy, NULL);
 	}
       if (this->align_ != NULL)
 	{
@@ -1869,7 +1875,7 @@ Output_section_definition::finalize_symb
 	  uint64_t align = this->align_->eval_with_dot(symtab, layout, true,
 						       *dot_value,
 						       NULL,
-						       &dummy);
+						       &dummy, NULL);
 	  address = align_address(address, align);
 	}
       *dot_value = address;
@@ -1918,6 +1924,7 @@ void
 Output_section_definition::set_section_addresses(Symbol_table* symtab,
 						 Layout* layout,
 						 uint64_t* dot_value,
+						 uint64_t* dot_alignment,
                                                  uint64_t* load_address)
 {
   uint64_t address;
@@ -1930,7 +1937,8 @@ Output_section_definition::set_section_a
     {
       Output_section* dummy;
       address = this->address_->eval_with_dot(symtab, layout, true,
-					      *dot_value, NULL, &dummy);
+					      *dot_value, NULL, &dummy,
+					      dot_alignment);
     }
 
   uint64_t align;
@@ -1945,7 +1953,7 @@ Output_section_definition::set_section_a
     {
       Output_section* align_section;
       align = this->align_->eval_with_dot(symtab, layout, true, *dot_value,
-					  NULL, &align_section);
+					  NULL, &align_section, NULL);
       if (align_section != NULL)
 	gold_warning(_("alignment of section %s is not absolute"),
 		     this->name_.c_str());
@@ -1976,7 +1984,8 @@ Output_section_definition::set_section_a
       Output_section* dummy;
       uint64_t laddr =
 	this->load_address_->eval_with_dot(symtab, layout, true, *dot_value,
-					   this->output_section_, &dummy);
+					   this->output_section_, &dummy,
+					   NULL);
       if (this->output_section_ != NULL)
         this->output_section_->set_load_address(laddr);
       this->evaluated_load_address_ = laddr;
@@ -1990,7 +1999,7 @@ Output_section_definition::set_section_a
       Output_section* subalign_section;
       subalign = this->subalign_->eval_with_dot(symtab, layout, true,
 						*dot_value, NULL,
-						&subalign_section);
+						&subalign_section, NULL);
       if (subalign_section != NULL)
 	gold_warning(_("subalign of section %s is not absolute"),
 		     this->name_.c_str());
@@ -2004,8 +2013,8 @@ Output_section_definition::set_section_a
       Output_section* fill_section;
       uint64_t fill_val = this->fill_->eval_with_dot(symtab, layout, true,
 						     *dot_value,
-						     NULL,
-						     &fill_section);
+						     NULL, &fill_section,
+						     NULL);
       if (fill_section != NULL)
 	gold_warning(_("fill of section %s is not absolute"),
 		     this->name_.c_str());
@@ -2031,8 +2040,8 @@ Output_section_definition::set_section_a
        p != this->elements_.end();
        ++p)
     (*p)->set_section_addresses(symtab, layout, this->output_section_,
-				subalign, dot_value, &dot_section, &fill,
-				&input_sections);
+				subalign, dot_value, dot_alignment,
+				&dot_section, &fill, &input_sections);
 
   gold_assert(input_sections.empty());
 
@@ -2339,7 +2348,8 @@ class Orphan_output_section : public Sec
 
   // Set section addresses.
   void
-  set_section_addresses(Symbol_table*, Layout*, uint64_t*, uint64_t*);
+  set_section_addresses(Symbol_table*, Layout*, uint64_t*, uint64_t*,
+			uint64_t*);
 
   // Get the list of segments to use for an allocated section when
   // using a PHDRS clause.
@@ -2368,6 +2378,7 @@ class Orphan_output_section : public Sec
 void
 Orphan_output_section::set_section_addresses(Symbol_table*, Layout*,
 					     uint64_t* dot_value,
+					     uint64_t*,
                                              uint64_t* load_address)
 {
   typedef std::list<Output_section::Simple_input_section> Input_section_list;
@@ -2950,6 +2961,7 @@ Script_sections::set_section_addresses(S
 
   // For a relocatable link, we implicitly set dot to zero.
   uint64_t dot_value = 0;
+  uint64_t dot_alignment = 0;
   uint64_t load_address = 0;
 
   // Check to see if we want to use any of -Ttext, -Tdata and -Tbss options
@@ -2995,7 +3007,8 @@ Script_sections::set_section_addresses(S
 	    }
 	}
 
-      (*p)->set_section_addresses(symtab, layout, &dot_value, &load_address);
+      (*p)->set_section_addresses(symtab, layout, &dot_value, &dot_alignment,
+				  &load_address);
     } 
 
   if (this->phdrs_elements_ != NULL)
@@ -3006,7 +3019,7 @@ Script_sections::set_section_addresses(S
 	(*p)->eval_load_address(symtab, layout);
     }
 
-  return this->create_segments(layout);
+  return this->create_segments(layout, dot_alignment);
 }
 
 // Sort the sections in order to put them into segments.
@@ -3114,7 +3127,7 @@ Script_sections::header_size_adjustment(
 // if any.
 
 Output_segment*
-Script_sections::create_segments(Layout* layout)
+Script_sections::create_segments(Layout* layout, uint64_t dot_alignment)
 {
   gold_assert(this->saw_sections_clause_);
 
@@ -3122,7 +3135,7 @@ Script_sections::create_segments(Layout*
     return NULL;
 
   if (this->saw_phdrs_clause())
-    return create_segments_from_phdrs_clause(layout);
+    return create_segments_from_phdrs_clause(layout, dot_alignment);
 
   Layout::Section_list sections;
   layout->get_allocated_sections(&sections);
@@ -3195,6 +3208,7 @@ Script_sections::create_segments(Layout*
 	  current_seg = layout->make_output_segment(elfcpp::PT_LOAD,
 						    seg_flags);
 	  current_seg->set_addresses(vma, lma);
+	  current_seg->set_minimum_p_align(dot_alignment);
 	  if (first_seg == NULL)
 	    first_seg = current_seg;
 	  is_current_seg_readonly = true;
@@ -3388,10 +3402,11 @@ Script_sections::expected_segment_count(
 // should hold the file header and program headers, if any.
 
 Output_segment*
-Script_sections::create_segments_from_phdrs_clause(Layout* layout)
+Script_sections::create_segments_from_phdrs_clause(Layout* layout,
+						   uint64_t dot_alignment)
 {
   this->attach_sections_using_phdrs_clause(layout);
-  return this->set_phdrs_clause_addresses(layout);
+  return this->set_phdrs_clause_addresses(layout, dot_alignment);
 }
 
 // Create the segments from the PHDRS clause, and put the output
@@ -3485,7 +3500,8 @@ Script_sections::attach_sections_using_p
 // if any.
 
 Output_segment*
-Script_sections::set_phdrs_clause_addresses(Layout* layout)
+Script_sections::set_phdrs_clause_addresses(Layout* layout,
+					    uint64_t dot_alignment)
 {
   Output_segment* load_seg = NULL;
   for (Phdrs_elements::const_iterator p = this->phdrs_elements_->begin();
@@ -3508,6 +3524,8 @@ Script_sections::set_phdrs_clause_addres
 	  continue;
 	}
 
+      oseg->set_minimum_p_align(dot_alignment);
+
       // The output sections should have addresses from the SECTIONS
       // clause.  The addresses don't have to be in order, so find the
       // one with the lowest load address.  Use that to set the
Index: script-sections.h
===================================================================
RCS file: /cvs/src/src/gold/script-sections.h,v
retrieving revision 1.11
diff -p -u -r1.11 script-sections.h
--- script-sections.h	9 Apr 2010 17:32:58 -0000	1.11
+++ script-sections.h	23 Apr 2010 04:37:11 -0000
@@ -232,7 +232,7 @@ class Script_sections
 
   // Create segments.
   Output_segment*
-  create_segments(Layout*);
+  create_segments(Layout*, uint64_t);
 
   // Create PT_NOTE and PT_TLS segments.
   void
@@ -253,7 +253,7 @@ class Script_sections
 
   // Create the segments from a PHDRS clause.
   Output_segment*
-  create_segments_from_phdrs_clause(Layout* layout);
+  create_segments_from_phdrs_clause(Layout* layout, uint64_t);
 
   // Attach sections to segments from a PHDRS clause.
   void
@@ -261,7 +261,7 @@ class Script_sections
 
   // Set addresses of segments from a PHDRS clause.
   Output_segment*
-  set_phdrs_clause_addresses(Layout*);
+  set_phdrs_clause_addresses(Layout*, uint64_t);
 
   // True if we ever saw a SECTIONS clause.
   bool saw_sections_clause_;
Index: script.cc
===================================================================
RCS file: /cvs/src/src/gold/script.cc,v
retrieving revision 1.70
diff -p -u -r1.70 script.cc
--- script.cc	9 Apr 2010 17:32:58 -0000	1.70
+++ script.cc	23 Apr 2010 04:37:11 -0000
@@ -955,7 +955,7 @@ Symbol_assignment::sized_finalize(Symbol
   uint64_t final_val = this->val_->eval_maybe_dot(symtab, layout, true,
 						  is_dot_available,
 						  dot_value, dot_section,
-						  &section);
+						  &section, NULL);
   Sized_symbol<size>* ssym = symtab->get_sized_symbol<size>(this->sym_);
   ssym->set_value(final_val);
   if (section != NULL)
@@ -974,7 +974,7 @@ Symbol_assignment::set_if_absolute(Symbo
   Output_section* val_section;
   uint64_t val = this->val_->eval_maybe_dot(symtab, layout, false,
 					    is_dot_available, dot_value,
-					    NULL, &val_section);
+					    NULL, &val_section, NULL);
   if (val_section != NULL)
     return;
 
Index: script.h
===================================================================
RCS file: /cvs/src/src/gold/script.h,v
retrieving revision 1.32
diff -p -u -r1.32 script.h
--- script.h	12 Jan 2010 06:41:36 -0000	1.32
+++ script.h	23 Apr 2010 04:37:12 -0000
@@ -86,11 +86,14 @@ class Expression
   // value is defined.  If the value is absolute *RESULT_SECTION will
   // be NULL.  Note that the returned value is still an absolute
   // value; to get a section relative value the caller must subtract
-  // the section address.
+  // the section address.  If RESULT_ALIGNMENT is not NULL, this sets
+  // *RESULT_ALIGNMENT to the alignment of the value of that alignment
+  // is larger than *RESULT_ALIGNMENT; this will only be non-zero if
+  // this is an ALIGN expression.
   uint64_t
   eval_with_dot(const Symbol_table*, const Layout*, bool check_assertions,
 		uint64_t dot_value, Output_section* dot_section,
-		Output_section** result_section);
+		Output_section** result_section, uint64_t* result_alignment);
 
   // Return the value of an expression which may or may not be
   // permitted to refer to the dot symbol, depending on
@@ -99,7 +102,7 @@ class Expression
   eval_maybe_dot(const Symbol_table*, const Layout*, bool check_assertions,
 		 bool is_dot_available, uint64_t dot_value,
 		 Output_section* dot_section,
-		 Output_section** result_section);
+		 Output_section** result_section, uint64_t* result_alignment);
 
   // Print the expression to the FILE.  This is for debugging.
   virtual void
Index: testsuite/script_test_3.sh
===================================================================
RCS file: /cvs/src/src/gold/testsuite/script_test_3.sh,v
retrieving revision 1.2
diff -p -u -r1.2 script_test_3.sh
--- testsuite/script_test_3.sh	10 Apr 2008 01:02:46 -0000	1.2
+++ testsuite/script_test_3.sh	23 Apr 2010 04:37:12 -0000
@@ -85,4 +85,18 @@ if test "$section_size" != "$segment_siz
   exit 1
 fi
 
+# At least one PT_LOAD segment should have an alignment >= 0x100000.
+found=no
+for a in `grep LOAD script_test_3.stdout | sed -e 's/^.* 0x/0x/'`; do
+  script="BEGIN { if ($a >= 0x100000) { print \"true\" } else { print \"false\" } }"
+  x=`awk "$script" < /dev/null`
+  if test "$x" = "true"; then
+    found=yes
+  fi
+done
+if test "$found" = "no"; then
+  echo "no LOAD segment has required alignment"
+  exit 1
+fi
+
 exit 0
Index: testsuite/script_test_3.t
===================================================================
RCS file: /cvs/src/src/gold/testsuite/script_test_3.t,v
retrieving revision 1.3
diff -p -u -r1.3 script_test_3.t
--- testsuite/script_test_3.t	24 Mar 2010 18:12:48 -0000	1.3
+++ testsuite/script_test_3.t	23 Apr 2010 04:37:12 -0000
@@ -35,7 +35,7 @@ SECTIONS
   .tdata : { *(.tdata*) } :data :tls
   .tbss : { *(.tbss*) } :data :tls
   . += 0x100000;
-  . = ALIGN(0x100);
+  . = ALIGN(0x100000);
   .bss : { *(.bss) } :bss
 }
 

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[H.J. Lu]

On Thu, Apr 22, 2010 at 9:49 PM, Ian Lance Taylor <iant@google.com> wrote:
> John Reiser <jreiser@bitwagon.com> writes:
>
>>> Linux kernel linker scripts needs to align .rodata section to 2MB:
>>>
>>> . = ALIGN((1<<  21));
>>>
>>> Since gold can only align to 4K, gold can't be used on Linux
>>> kernel.
>>
>> The linker script statement ". = ALIGN((1<<  21));" requires alignment
>> to 2 MiB.  If gold "can only align to 4 KiB", then gold must emit an
>> error message upon processing input that requires a larger alignment.
>> It is a bug that current gold does not emit such a message for this case.
>
> The problem is that the alignment requested by the linker script is
> not reflected in the linker output.  That actually appears to be true
> of the GNU linker as well.  Logically, an alignment requested in the
> linker script should be reflected in the program segments.
>
> I committed this patch to make an alignment requested in the linker
> script be reflected in the p_align field of the generated program
> headers.  I don't know if this actually fixes the problem, but it
> seems like the right thing to do.
>

It can get quite complicated. What if there is an input with

---
	.text
	.p2align 23
foo:
	nop
---

I think the best linker can do is to issue an error.



-- 
H.J.

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[Ian Lance Taylor]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> It can get quite complicated. What if there is an input with
>
> ---
> 	.text
> 	.p2align 23
> foo:
> 	nop
> ---
>
> I think the best linker can do is to issue an error.

As far as I know that case is already handled just fine.  The
assembler should put the required alignment in the sh_align field of
the section header.  The linker should honor that alignment when
setting the section address, and should also copy the alignment into
the p_align field of the program header.

The case I just changed was where the alignment was not reflected in
any sh_align field, but was only due to use of ALIGN in a linker
script.

What do you think will go wrong with the above?  Is your concern that
the operating system will not be able to align the physical memory
address as required by the program header alignment?  I don't see why
that would matter on a virtual memory system.

Ian

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[H.J. Lu]

On Fri, Apr 23, 2010 at 7:12 AM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> It can get quite complicated. What if there is an input with
>>
>> ---
>>       .text
>>       .p2align 23
>> foo:
>>       nop
>> ---
>>
>> I think the best linker can do is to issue an error.
>
> As far as I know that case is already handled just fine.  The
> assembler should put the required alignment in the sh_align field of
> the section header.  The linker should honor that alignment when
> setting the section address, and should also copy the alignment into
> the p_align field of the program header.
>
> The case I just changed was where the alignment was not reflected in
> any sh_align field, but was only due to use of ALIGN in a linker
> script.
>
> What do you think will go wrong with the above?  Is your concern that
> the operating system will not be able to align the physical memory
> address as required by the program header alignment?  I don't see why
> that would matter on a virtual memory system.
>

Gold generates:

[hjl@gnu-6 alignment-2]$ cat foo.s
	.text
	.byte 0
	.p2align 14
	.data
foo:
	.byte 1
[hjl@gnu-6 alignment-2]$ cat foo.ld
SECTIONS
{
  . = 0x1000;
  PROVIDE (foo = .);
  .data : { *(.data) }
  .dynamic : { *(.dynamic) }
}
[hjl@gnu-6 alignment-2]$ gcc -c foo.s
[hjl@gnu-6 alignment-2]$ ld.gold -z max-page-size=0x1000 -o libfoo.so
-T foo.ld foo.o
[hjl@gnu-6 alignment-2]$ readelf -lS libfoo.so
There are 8 section headers, starting at offset 0x8090:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .data             PROGBITS         0000000000001000  00001000
       0000000000000001  0000000000000000  WA       0     0     4
  [ 2] .bss              NOBITS           0000000000001004  00001004
       0000000000000000  0000000000000000  WA       0     0     4
  [ 3] .text             PROGBITS         0000000000004000  00002000
       0000000000006000  0000000000000000  AX       0     0     16384
  [ 4] .note.gnu.gold-ve NOTE             0000000000000000  00008000
       0000000000000018  0000000000000000           0     0     4
  [ 5] .symtab           SYMTAB           0000000000000000  00008018
       0000000000000030  0000000000000018           6     2     8
  [ 6] .strtab           STRTAB           0000000000000000  00008048
       0000000000000005  0000000000000000           0     0     1
  [ 7] .shstrtab         STRTAB           0000000000000000  0000804d
       0000000000000043  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Elf file type is EXEC (Executable file)
Entry point 0x0
There are 3 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x00000000000000e8 0x00000000000000e8  R      1000
  LOAD           0x0000000000001000 0x0000000000001000 0x0000000000001000
                 0x0000000000000001 0x0000000000000004  RW     1000
  LOAD           0x0000000000002000 0x0000000000004000 0x0000000000004000
                 0x0000000000006000 0x0000000000006000  R E    4000

 Section to Segment mapping:
  Segment Sections...
   00
   01     .data
   02     .text
[hjl@gnu-6 alignment-2]$

It doesn't look right to me:

1. foo isn't aligned at 1<<14 bytes.
2. -z max-page-size=0x1000 isn' honored on the last segment.

-- 
H.J.

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[Ian Lance Taylor]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> [hjl@gnu-6 alignment-2]$ cat foo.s
> 	.text
> 	.byte 0
> 	.p2align 14
> 	.data
> foo:
> 	.byte 1

Note that the .p2align directive here applies to the .text section,
not to the .data section.

> 1. foo isn't aligned at 1<<14 bytes.

You didn't ask it to be.

> 2. -z max-page-size=0x1000 isn' honored on the last segment.

I don't know what you mean here.

Ian

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[H.J. Lu]

On Fri, Apr 23, 2010 at 7:43 AM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> [hjl@gnu-6 alignment-2]$ cat foo.s
>>       .text
>>       .byte 0
>>       .p2align 14
>>       .data
>> foo:
>>       .byte 1
>
> Note that the .p2align directive here applies to the .text section,
> not to the .data section.
>
>> 1. foo isn't aligned at 1<<14 bytes.
>
> You didn't ask it to be.

Wrong test.

>> 2. -z max-page-size=0x1000 isn' honored on the last segment.
>
> I don't know what you mean here.

User asked maximum page size to be 0x1000 and gold does
something else. I don't know if the resulting binary is valid
or not since p_align are different on 2 LOAD segments.



-- 
H.J.

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[Ian Lance Taylor]

"H.J. Lu" <hjl.tools@gmail.com> writes:

>>> 2. -z max-page-size=0x1000 isn' honored on the last segment.
>>
>> I don't know what you mean here.
>
> User asked maximum page size to be 0x1000 and gold does
> something else. I don't know if the resulting binary is valid
> or not since p_align are different on 2 LOAD segments.

Unfortunately the -z max-page-size option is poorly documented.  What
do we think it should mean?  For the GNU linker, the option has two
effects: 1) set the value for CONSTANT (MAXPAGESIZE) in a linker
script; 2) set the default value for page alignment of program
headers.

In practice it sets the minimum page size to use for a demand paged
executable.  You seem to be suggesting that it should also set a
maximum page size, in effect suggesting that it should be the exact
page size to use.  Is that we want?

Ian

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[H.J. Lu]

On Fri, Apr 23, 2010 at 8:31 AM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>>>> 2. -z max-page-size=0x1000 isn' honored on the last segment.
>>>
>>> I don't know what you mean here.
>>
>> User asked maximum page size to be 0x1000 and gold does
>> something else. I don't know if the resulting binary is valid
>> or not since p_align are different on 2 LOAD segments.
>
> Unfortunately the -z max-page-size option is poorly documented.  What
> do we think it should mean?  For the GNU linker, the option has two
> effects: 1) set the value for CONSTANT (MAXPAGESIZE) in a linker
> script; 2) set the default value for page alignment of program
> headers.

In practice, they are the same thing.

> In practice it sets the minimum page size to use for a demand paged
> executable.  You seem to be suggesting that it should also set a
> maximum page size, in effect suggesting that it should be the exact
> page size to use.  Is that we want?

p_align is the maximum page size. I don't know where the minimum
page size comes from.


-- 
H.J.

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[H.J. Lu]

On Fri, Apr 23, 2010 at 7:35 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Apr 23, 2010 at 7:12 AM, Ian Lance Taylor <iant@google.com> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>> It can get quite complicated. What if there is an input with
>>>
>>> ---
>>>       .text
>>>       .p2align 23
>>> foo:
>>>       nop
>>> ---
>>>
>>> I think the best linker can do is to issue an error.
>>
>> As far as I know that case is already handled just fine.  The
>> assembler should put the required alignment in the sh_align field of
>> the section header.  The linker should honor that alignment when
>> setting the section address, and should also copy the alignment into
>> the p_align field of the program header.
>>
>> The case I just changed was where the alignment was not reflected in
>> any sh_align field, but was only due to use of ALIGN in a linker
>> script.
>>
>> What do you think will go wrong with the above?  Is your concern that
>> the operating system will not be able to align the physical memory
>> address as required by the program header alignment?  I don't see why
>> that would matter on a virtual memory system.
>>
>
> Gold generates:
>

>
> It doesn't look right to me:
>
> 1. foo isn't aligned at 1<<14 bytes.
> 2. -z max-page-size=0x1000 isn' honored on the last segment.

Wrong tests. Here is the right one

[hjl@gnu-6 alignment-2]$ cat foo.s
	.text
	.byte 0
	.data
	.p2align 14
foo:
	.byte 1
[hjl@gnu-6 alignment-2]$ cat foo.ld
SECTIONS
{
  .text : { *(.text) }
  .data : { *(.data) }
  .dynamic : { *(.dynamic) }
  /DISCARD/ : { *(.*) }
}
[hjl@gnu-6 alignment-2]$ gcc -c foo.s
[hjl@gnu-6 alignment-2]$ ld.gold -z max-page-size=0x1000 -o libfoo.so
-T foo.ld foo.o
[hjl@gnu-6 alignment-2]$ readelf -Sl libfoo.so
~/bugs/binutils/alignment-2

File: libfoo.so
There are 6 section headers, starting at offset 0x4068:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000000000  00001000
       0000000000000001  0000000000000000  AX       0     0     4
  [ 2] .data             PROGBITS         0000000000004000  00002000
       0000000000002001  0000000000000000  WA       0     0     16384
  [ 3] .symtab           SYMTAB           0000000000000000  00004008
       0000000000000030  0000000000000018           4     2     8
  [ 4] .strtab           STRTAB           0000000000000000  00004038
       0000000000000005  0000000000000000           0     0     1
  [ 5] .shstrtab         STRTAB           0000000000000000  0000403d
       0000000000000027  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Elf file type is EXEC (Executable file)
Entry point 0x0
There are 2 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000001000 0x0000000000000000 0x0000000000000000
                 0x0000000000000001 0x0000000000000001  R E    1000
  LOAD           0x0000000000002000 0x0000000000004000 0x0000000000004000
                 0x0000000000002001 0x0000000000002001  RW     4000

 Section to Segment mapping:
  Segment Sections...
   00     .text
   01     .data

gABI says:

---
p_align
    As ``Program Loading'' describes in this chapter of the processor
supplement, loadable process segments must have congruent values for
p_vaddr and p_offset, modulo the page size. This member gives the
value to which the segments are aligned in memory and in the file.
Values 0 and 1 mean no alignment is required. Otherwise, p_align
should be a positive, integral power of 2, and p_vaddr should equal
p_offset, modulo p_align.
----

I am not sure it is a good idea to have different p_align.


-- 
H.J.

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[Ian Lance Taylor]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> Program Headers:
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
>   LOAD           0x0000000000001000 0x0000000000000000 0x0000000000000000
>                  0x0000000000000001 0x0000000000000001  R E    1000
>   LOAD           0x0000000000002000 0x0000000000004000 0x0000000000004000
>                  0x0000000000002001 0x0000000000002001  RW     4000

This looks right to me.


> I am not sure it is a good idea to have different p_align.

Why not?  How else can we communicate the information requested by the
programmer?  A system which cares about p_align needs to look at the
p_align of each PT_LOAD header.

Ian

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[H.J. Lu]

On Fri, Apr 23, 2010 at 8:16 AM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> Program Headers:
>>   Type           Offset             VirtAddr           PhysAddr
>>                  FileSiz            MemSiz              Flags  Align
>>   LOAD           0x0000000000001000 0x0000000000000000 0x0000000000000000
>>                  0x0000000000000001 0x0000000000000001  R E    1000
>>   LOAD           0x0000000000002000 0x0000000000004000 0x0000000000004000
>>                  0x0000000000002001 0x0000000000002001  RW     4000
>
> This looks right to me.
>
>
>> I am not sure it is a good idea to have different p_align.
>
> Why not?  How else can we communicate the information requested by the
> programmer?  A system which cares about p_align needs to look at the
> p_align of each PT_LOAD header.

You can't load the first segment with 0x1000 alignment. You
need to load the first segment with the alignment of the second
segment. Why does gold have to make life harder for loader?


-- 
H.J.

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[Ian Lance Taylor]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Fri, Apr 23, 2010 at 8:16 AM, Ian Lance Taylor <iant@google.com> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>> Program Headers:
>>>   Type           Offset             VirtAddr           PhysAddr
>>>                  FileSiz            MemSiz              Flags  Align
>>>   LOAD           0x0000000000001000 0x0000000000000000 0x0000000000000000
>>>                  0x0000000000000001 0x0000000000000001  R E    1000
>>>   LOAD           0x0000000000002000 0x0000000000004000 0x0000000000004000
>>>                  0x0000000000002001 0x0000000000002001  RW     4000
>>
>> This looks right to me.
>>
>>
>>> I am not sure it is a good idea to have different p_align.
>>
>> Why not?  How else can we communicate the information requested by the
>> programmer?  A system which cares about p_align needs to look at the
>> p_align of each PT_LOAD header.
>
> You can't load the first segment with 0x1000 alignment. You
> need to load the first segment with the alignment of the second
> segment. Why does gold have to make life harder for loader?

The Linux kernel doesn't look at the p_align field, nor should it.
The p_align field is clearly irrelevant when loading an executable.
The glibc dynamic linker checks that the p_align field looks
plausible, but otherwise ignores it other than for a PT_TLS segment;
that seems appropriate since ld.so is restricted to what mmap does
anyhow.  In general, it's hard for me to think of why any loader on a
virtual memory system would look at the p_align field.  And it's hard
for to think of any non-virtual memory system that would support ELF
style shared libraries.

So I think you are raising a purely hypothetical concern.

On the other hand the p_align field does convey information about the
sections in that particular segment, and that seems reasonable to me.

Ian

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[H.J. Lu]

On Fri, Apr 23, 2010 at 8:49 AM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> On Fri, Apr 23, 2010 at 8:16 AM, Ian Lance Taylor <iant@google.com> wrote:
>>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>>
>>>> Program Headers:
>>>>   Type           Offset             VirtAddr           PhysAddr
>>>>                  FileSiz            MemSiz              Flags  Align
>>>>   LOAD           0x0000000000001000 0x0000000000000000 0x0000000000000000
>>>>                  0x0000000000000001 0x0000000000000001  R E    1000
>>>>   LOAD           0x0000000000002000 0x0000000000004000 0x0000000000004000
>>>>                  0x0000000000002001 0x0000000000002001  RW     4000
>>>
>>> This looks right to me.
>>>
>>>
>>>> I am not sure it is a good idea to have different p_align.
>>>
>>> Why not?  How else can we communicate the information requested by the
>>> programmer?  A system which cares about p_align needs to look at the
>>> p_align of each PT_LOAD header.
>>
>> You can't load the first segment with 0x1000 alignment. You
>> need to load the first segment with the alignment of the second
>> segment. Why does gold have to make life harder for loader?
>
> The Linux kernel doesn't look at the p_align field, nor should it.
> The p_align field is clearly irrelevant when loading an executable.
> The glibc dynamic linker checks that the p_align field looks
> plausible, but otherwise ignores it other than for a PT_TLS segment;
> that seems appropriate since ld.so is restricted to what mmap does
> anyhow.  In general, it's hard for me to think of why any loader on a
> virtual memory system would look at the p_align field.  And it's hard
> for to think of any non-virtual memory system that would support ELF
> style shared libraries.
>
> So I think you are raising a purely hypothetical concern.
>
> On the other hand the p_align field does convey information about the
> sections in that particular segment, and that seems reasonable to me.
>

See:

http://www.sourceware.org/bugzilla/show_bug.cgi?id=11533


-- 
H.J.

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[John Reiser]

On 04/23/2010 08:30 AM, H.J. Lu wrote:
> You can't load the first segment with 0x1000 alignment. You
> need to load the first segment with the alignment of the second
> segment. Why does gold have to make life harder for loader?

Each PT_LOAD is a *segment* with separate attributes.  There is
no guarantee that a single read() or mmap() can necessarily handle
more than one PT_LOAD at a time, although it does work in many cases.
Both execve() and dlopen() iterate over ElfXX_Phdr, processing each
PT_LOAD separately.  A boot loader must do likewise.  For instance
ELF makes no guarantee that the PT_LOAD are in ascending order by
.p_vaddr or .p_paddr.

-- 

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[John Reiser]

On 04/23/2010 07:12 AM, Ian Lance Taylor wrote:
>> 	.text
>> 	.p2align 23
    [[snip]]
> Is your concern that
> the operating system will not be able to align the physical memory
> address as required by the program header alignment?  I don't see why
> that would matter on a virtual memory system.

The hardware should not care, but the software might.  For instance,
if the alignment is honored on a 32-bit system, then a pointer to
the beginning of the area can be represented using only (32 - 23) = 9
bits, which offers an opportunity to reduce storage costs.  Also,
that much alignment often can exert an influence on the performance
of caches (including TLB), particularly by reducing the variability
from run to run.

-- 

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[Török Edwin]

On 04/23/2010 07:49 AM, Ian Lance Taylor wrote:
> John Reiser <jreiser@bitwagon.com> writes:
> 
>>> Linux kernel linker scripts needs to align .rodata section to 2MB:
>>>
>>> . = ALIGN((1<<  21));
>>>
>>> Since gold can only align to 4K, gold can't be used on Linux
>>> kernel.
>>
>> The linker script statement ". = ALIGN((1<<  21));" requires alignment
>> to 2 MiB.  If gold "can only align to 4 KiB", then gold must emit an
>> error message upon processing input that requires a larger alignment.
>> It is a bug that current gold does not emit such a message for this case.
> 
> The problem is that the alignment requested by the linker script is
> not reflected in the linker output.  That actually appears to be true
> of the GNU linker as well.  Logically, an alignment requested in the
> linker script should be reflected in the program segments.
> 
> I committed this patch to make an alignment requested in the linker
> script be reflected in the p_align field of the generated program
> headers.  I don't know if this actually fixes the problem, but it
> seems like the right thing to do.

With latest CVS gold I get this error:
objcopy  -R .comment -S vmlinux arch/x86/boot/compressed/vmlinux.bin
objcopy:arch/x86/boot/compressed/vmlinux.bin[.text]: File truncated
objcopy:arch/x86/boot/compressed/vmlinux.bin: File truncated

Looks like objcopy doesn't like something about vmlinux.

$ ls -l vmlinux
-rwxr-xr-x 1 edwin edwin 10879216 Apr 23 16:58 vmlinux

strace of the obcopy:

lseek(5, 64, SEEK_CUR)                  = 64
write(5,
"\1\0\0\0\5\0\0\0@Ld\257D\v\0\0\0\0\0\201\377\377\377\377\0\0\0\1\0\0\0\0"...,
336) = 336
lseek(5, 12389628264448, SEEK_SET)      = -1 EINVAL (Invalid argument)
write(2, "objcopy", 7objcopy)                  = 7
write(2, ":arch/x86/boot/compressed/vmlinu"...,
44:arch/x86/boot/compressed/vmlinux.bin[.text]) = 44
write(2, ": File truncated\n", 17: File truncated

See the ELF headers below.
Should I upload vmlinux to the bugreport? (or some other file?)

Section Headers:
[Nr] Name                 Type         Addr             Off      Size
  ES Flags Lk Inf Al
[ 0]                      NULL         0000000000000000 00000000
00000000  0        0   0  0
[ 1] .text                PROGBITS     ffffffff81000000 00001000
003d1c15  0 AX     0   0 4096
[ 2] .notes               NOTE         ffffffff813d1c18 003d2c18
00000024  0 A      0   0  4
[ 3] __ex_table           PROGBITS     ffffffff813d1c40 003d2c40
000040c0  0 A      0   0  8
[ 4] .rodata              PROGBITS     ffffffff81400000 00401000
001b7222  0 A      0   0 64
[ 5] __bug_table          PROGBITS     ffffffff815b7228 005b8228
000054a8  0 A      0   0  1
[ 6] .pci_fixup           PROGBITS     ffffffff815bc6d0 005bd6d0
00001720  0 A      0   0 16
[ 7] __ksymtab            PROGBITS     ffffffff815bddf0 005bedf0
0000bc80  0 A      0   0 16
[ 8] __ksymtab_gpl        PROGBITS     ffffffff815c9a70 005caa70
00005e30  0 A      0   0 16
[ 9] __kcrctab            PROGBITS     ffffffff815cf8a0 005d08a0
00005e40  0 A      0   0  8
[10] __kcrctab_gpl        PROGBITS     ffffffff815d56e0 005d66e0
00002f18  0 A      0   0  8
[11] __ksymtab_strings    PROGBITS     ffffffff815d85f8 005d95f8
00013e53  0 A      0   0  1
[12] __init_rodata        PROGBITS     ffffffff815ec450 005ed450
00003bc0  0 A      0   0 16
[13] __param              PROGBITS     ffffffff815f0010 005f1010
00001ff0  0 A      0   0  8
[14] .data                PROGBITS     ffffffff81600000 005f3000
00183220  0 WA     0   0 4096
[15] .vsyscall_0          PROGBITS     ffffffffff600000 00777000
000000ce  0 AX     0   0  1
[16] .vsyscall_fn         PROGBITS     ffffffffff600100 00777100
0000003f  0 AX     0   0  1
[17] .vsyscall_gtod_data  PROGBITS     ffffffffff600140 00777140
00000060  0 WA     0   0 16
[18] .vsyscall_1          PROGBITS     ffffffffff600400 00777400
0000003c  0 AX     0   0  1
[19] .vsyscall_2          PROGBITS     ffffffffff600800 00777800
00000066  0 AX     0   0  1
[20] .vgetcpu_mode        PROGBITS     ffffffffff600870 00777870
00000004  0 WA     0   0 16
[21] .jiffies             PROGBITS     ffffffffff600880 00777880
00000008  0 WA     0   0 16
[22] .data.percpu         PROGBITS     0000000000000000 00778000
00014628  0 WA     0   0 4096
[23] .init.text           PROGBITS     ffffffff8179a000 0078d000
0002fe1b  0 AX     0   0 16
[24] .init.data           PROGBITS     ffffffff817c9e20 007bce20
000353e0  0 WA     0   0 16
[25] .x86_cpu_dev.init    PROGBITS     ffffffff817ff200 007f2200
00000018  0 A      0   0  8
[26] .altinstructions     PROGBITS     ffffffff817ff218 007f2218
00000a4c  0 A      0   0  8
[27] .altinstr_replacement PROGBITS     ffffffff817ffc64 007f2c64
00000266  0 AX     0   0  1
[28] .exit.text           PROGBITS     ffffffff817ffeca 007f2eca
00000cbe  0 AX     0   0  1
[29] .smp_locks           PROGBITS     ffffffff81801000 007f4000
00009000  0 A      0   0  8
[30] .data_nosave         PROGBITS     ffffffff8180a000 007fd000
00001000  0 WA     0   0  4
[31] .bss                 NOBITS       ffffffff8180b000 007fe000
044db998  0 WA     0   0 4096
[32] .brk                 NOBITS       ffffffff85ce7000 04cda000
00020000  0 WA     0   0  1
[33] .comment             PROGBITS     0000000000000000 007fe000
0000001d  1 MS     0   0  1
[34] .symtab              SYMTAB       0000000000000000 007fe020
0013aa90 24       35 37444  8
[35] .strtab              STRTAB       0000000000000000 00938ab0
00126b68  0        0   0  1
[36] .shstrtab            STRTAB       0000000000000000 00a5f618
00000192  0        0   0  1

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz
 MemSiz   Flg Align
  LOAD           0x001000 0xffffffff81000000 0x0000000001000000 0x5f2000
0x5f2000 R E 0x7fff3a5e9140
  LOAD           0x5f3000 0xffffffff81600000 0x0000000001600000 0x183220
0x183220 RWE 0x7fff3a5e9140
  LOAD           0x777000 0xffffffffff600000 0x0000000001784000 0x000888
0x000888 R E 0x7fff3a5e9140
  LOAD           0x778000 0x0000000000000000 0x0000000001785000 0x014628
0x014628 RW  0x7fff3a5e9140
  LOAD           0x78d000 0xffffffff8179a000 0x000000000179a000 0x071000
0x456d000 RWE 0x7fff3a5e9140
  NOTE           0x3d2c18 0xffffffff813d1c18 0x00000000013d1c18 0x000024
0x000024     0x4

Best regards,
--Edwin

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[H.J. Lu]

2010/4/23 Török Edwin <edwintorok@gmail.com>:
> On 04/23/2010 07:49 AM, Ian Lance Taylor wrote:
>> John Reiser <jreiser@bitwagon.com> writes:
>>
>>>> Linux kernel linker scripts needs to align .rodata section to 2MB:
>>>>
>>>> . = ALIGN((1<<  21));
>>>>
>>>> Since gold can only align to 4K, gold can't be used on Linux
>>>> kernel.
>>>
>>> The linker script statement ". = ALIGN((1<<  21));" requires alignment
>>> to 2 MiB.  If gold "can only align to 4 KiB", then gold must emit an
>>> error message upon processing input that requires a larger alignment.
>>> It is a bug that current gold does not emit such a message for this case.
>>
>> The problem is that the alignment requested by the linker script is
>> not reflected in the linker output.  That actually appears to be true
>> of the GNU linker as well.  Logically, an alignment requested in the
>> linker script should be reflected in the program segments.
>>
>> I committed this patch to make an alignment requested in the linker
>> script be reflected in the p_align field of the generated program
>> headers.  I don't know if this actually fixes the problem, but it
>> seems like the right thing to do.
>
> With latest CVS gold I get this error:
> objcopy  -R .comment -S vmlinux arch/x86/boot/compressed/vmlinux.bin
> objcopy:arch/x86/boot/compressed/vmlinux.bin[.text]: File truncated
> objcopy:arch/x86/boot/compressed/vmlinux.bin: File truncated
>
> Looks like objcopy doesn't like something about vmlinux.
>
> $ ls -l vmlinux
> -rwxr-xr-x 1 edwin edwin 10879216 Apr 23 16:58 vmlinux
>

>
> Program Headers:
>  Type           Offset   VirtAddr           PhysAddr           FileSiz
>  MemSiz   Flg Align
>  LOAD           0x001000 0xffffffff81000000 0x0000000001000000 0x5f2000
> 0x5f2000 R E 0x7fff3a5e9140
>  LOAD           0x5f3000 0xffffffff81600000 0x0000000001600000 0x183220
> 0x183220 RWE 0x7fff3a5e9140
>  LOAD           0x777000 0xffffffffff600000 0x0000000001784000 0x000888
> 0x000888 R E 0x7fff3a5e9140
>  LOAD           0x778000 0x0000000000000000 0x0000000001785000 0x014628
> 0x014628 RW  0x7fff3a5e9140
>  LOAD           0x78d000 0xffffffff8179a000 0x000000000179a000 0x071000
> 0x456d000 RWE 0x7fff3a5e9140
>  NOTE           0x3d2c18 0xffffffff813d1c18 0x00000000013d1c18 0x000024
> 0x000024     0x4
>

If it is generated by gold, its p_align fields are bogus.


-- 
H.J.

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[Török Edwin]

On 04/23/2010 05:48 PM, H.J. Lu wrote:
>>
>> Program Headers:
>>  Type           Offset   VirtAddr           PhysAddr           FileSiz
>>  MemSiz   Flg Align
>>  LOAD           0x001000 0xffffffff81000000 0x0000000001000000 0x5f2000
>> 0x5f2000 R E 0x7fff3a5e9140
>>  LOAD           0x5f3000 0xffffffff81600000 0x0000000001600000 0x183220
>> 0x183220 RWE 0x7fff3a5e9140
>>  LOAD           0x777000 0xffffffffff600000 0x0000000001784000 0x000888
>> 0x000888 R E 0x7fff3a5e9140
>>  LOAD           0x778000 0x0000000000000000 0x0000000001785000 0x014628
>> 0x014628 RW  0x7fff3a5e9140
>>  LOAD           0x78d000 0xffffffff8179a000 0x000000000179a000 0x071000
>> 0x456d000 RWE 0x7fff3a5e9140
>>  NOTE           0x3d2c18 0xffffffff813d1c18 0x00000000013d1c18 0x000024
>> 0x000024     0x4
>>
> 
> If it is generated by gold, its p_align fields are bogus.

Yes it was generated by gold.

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[Ian Lance Taylor]

Török Edwin <edwintorok@gmail.com> writes:

> With latest CVS gold I get this error:
> objcopy  -R .comment -S vmlinux arch/x86/boot/compressed/vmlinux.bin
> objcopy:arch/x86/boot/compressed/vmlinux.bin[.text]: File truncated
> objcopy:arch/x86/boot/compressed/vmlinux.bin: File truncated

Can you send me a copy of the linker script used to create vmlinux?
You should be able to see this from the command line--it is most
likely passed in using a -T option.

Ian

Re: gold patch committed (Was: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel)

[Török Edwin]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

On 04/24/2010 02:29 AM, Ian Lance Taylor wrote:
> Török Edwin <edwintorok@gmail.com> writes:
> 
>> With latest CVS gold I get this error:
>> objcopy  -R .comment -S vmlinux arch/x86/boot/compressed/vmlinux.bin
>> objcopy:arch/x86/boot/compressed/vmlinux.bin[.text]: File truncated
>> objcopy:arch/x86/boot/compressed/vmlinux.bin: File truncated
> 
> Can you send me a copy of the linker script used to create vmlinux?
> You should be able to see this from the command line--it is most
> likely passed in using a -T option.

Sure, attached.

Best regards,
--Edwin

[-- Attachment #2: vmlinux.lds --]
[-- Type: text/plain, Size: 26432 bytes --]

/*
 * Automatically generated C config: don't edit
 * Linux kernel version: 2.6.34-rc3
 * Fri Apr 23 16:50:37 2010
 */
/*
 * ld script for the x86 kernel
 *
 * Historic 32-bit version written by Martin Mares <mj@atrey.karlin.mff.cuni.cz>
 *
 * Modernisation, unification and other changes and fixes:
 *   Copyright (C) 2007-2009  Sam Ravnborg <sam@ravnborg.org>
 *
 *
 * Don't define absolute symbols until and unless you know that symbol
 * value is should remain constant even if kernel image is relocated
 * at run time. Absolute symbols are not relocated. If symbol value should
 * change if kernel is relocated, make the symbol section relative and
 * put it inside the section definition.
 */
/*
 * Helper macros to support writing architecture specific
 * linker scripts.
 *
 * A minimal linker scripts has following content:
 * [This is a sample, architectures may have special requiriements]
 *
 * OUTPUT_FORMAT(...)
 * OUTPUT_ARCH(...)
 * ENTRY(...)
 * SECTIONS
 * {
 *	. = START;
 *	__init_begin = .;
 *	HEAD_TEXT_SECTION
 *	INIT_TEXT_SECTION(PAGE_SIZE)
 *	INIT_DATA_SECTION(...)
 *	PERCPU(PAGE_SIZE)
 *	__init_end = .;
 *
 *	_stext = .;
 *	TEXT_SECTION = 0
 *	_etext = .;
 *
 *      _sdata = .;
 *	RO_DATA_SECTION(PAGE_SIZE)
 *	RW_DATA_SECTION(...)
 *	_edata = .;
 *
 *	EXCEPTION_TABLE(...)
 *	NOTES
 *
 *	BSS_SECTION(0, 0, 0)
 *	_end = .;
 *
 *	STABS_DEBUG
 *	DWARF_DEBUG
 *
 *	DISCARDS		// must be the last
 * }
 *
 * [__init_begin, __init_end] is the init section that may be freed after init
 * [_stext, _etext] is the text section
 * [_sdata, _edata] is the data section
 *
 * Some of the included output section have their own set of constants.
 * Examples are: [__initramfs_start, __initramfs_end] for initramfs and
 *               [__nosave_begin, __nosave_end] for the nosave data
 */
/* Align . to a 8 byte boundary equals to maximum function alignment. */
/* The actual configuration determine if the init/exit sections
 * are handled as text/data or they can be discarded (which
 * often happens at runtime)
 */
/* .data section */
/*
 * Data section helpers
 */
/*
 * Read only Data
 */
/* RODATA & RO_DATA provided for backward compatibility.
 * All archs are supposed to use RO_DATA() */
/* .text section. Map to function alignment to avoid address changes
 * during second ld run in second ld pass when generating System.map */
/* sched.text is aling to function alignment to secure we have same
 * address even at second ld pass when generating System.map */
/* spinlock.text is aling to function alignment to secure we have same
 * address even at second ld pass when generating System.map */
/* Section used for early init (in .S files) */
/*
 * Exception table
 */
/*
 * Init task
 */
/* init and exit section handling */
/*
 * bss (Block Started by Symbol) - uninitialized data
 * zeroed during startup
 */
/*
 * DWARF debug sections.
 * Symbols in the DWARF debugging sections are relative to
 * the beginning of the section so we begin them at 0.
 */
  /* Stabs debugging sections.  */
/*
 * Default discarded sections.
 *
 * Some archs want to discard exit text/data at runtime rather than
 * link time due to cross-section references such as alt instructions,
 * bug table, eh_frame, etc.  DISCARDS must be the last of output
 * section definitions so that such archs put those in earlier section
 * definitions.
 */
/**
 * PERCPU_VADDR - define output section for percpu area
 * @vaddr: explicit base address (optional)
 * @phdr: destination PHDR (optional)
 *
 * Macro which expands to output section for percpu area.  If @vaddr
 * is not blank, it specifies explicit base address and all percpu
 * symbols will be offset from the given address.  If blank, @vaddr
 * always equals @laddr + LOAD_OFFSET.
 *
 * @phdr defines the output PHDR to use if not blank.  Be warned that
 * output PHDR is sticky.  If @phdr is specified, the next output
 * section in the linker script will go there too.  @phdr should have
 * a leading colon.
 *
 * Note that this macros defines __per_cpu_load as an absolute symbol.
 * If there is no need to put the percpu section at a predetermined
 * address, use PERCPU().
 */
/**
 * PERCPU - define output section for percpu area, simple version
 * @align: required alignment
 *
 * Align to @align and outputs output section for percpu area.  This
 * macro doesn't maniuplate @vaddr or @phdr and __per_cpu_load and
 * __per_cpu_start will be identical.
 *
 * This macro is equivalent to ALIGN(align); PERCPU_VADDR( , ) except
 * that __per_cpu_load is defined as a relative symbol against
 * .data.percpu which is required for relocatable x86_32
 * configuration.
 */
/*
 * Definition of the high level *_SECTION macros
 * They will fit only a subset of the architectures
 */
/*
 * Writeable data.
 * All sections are combined in a single .data section.
 * The sections following CONSTRUCTORS are arranged so their
 * typical alignment matches.
 * A cacheline is typical/always less than a PAGE_SIZE so
 * the sections that has this restriction (or similar)
 * is located before the ones requiring PAGE_SIZE alignment.
 * NOSAVE_DATA starts and ends with a PAGE_SIZE alignment which
 * matches the requirment of PAGE_ALIGNED_DATA.
 *
 * use 0 as page_align if page_aligned data is not used */
/*
 * DO NOT MODIFY.
 *
 * This file was generated by Kbuild
 *
 */
/* thread_info.h: low-level thread information
 *
 * Copyright (C) 2002  David Howells (dhowells@redhat.com)
 * - Incorporating suggestions made by Linus Torvalds and Dave Miller
 */
/*
 * Allow us to mark functions as 'deprecated' and have gcc emit a nice
 * warning for each use, in hopes of speeding the functions removal.
 * Usage is:
 * 		int __deprecated foo(void)
 */
/*
 * Allow us to avoid 'defined but not used' warnings on functions and data,
 * as well as force them to be emitted to the assembly file.
 *
 * As of gcc 3.4, static functions that are not marked with attribute((used))
 * may be elided from the assembly file.  As of gcc 3.4, static data not so
 * marked will not be elided, but this may change in a future gcc version.
 *
 * NOTE: Because distributions shipped with a backported unit-at-a-time
 * compiler in gcc 3.3, we must define __used to be __attribute__((used))
 * for gcc >=3.3 instead of 3.4.
 *
 * In prior versions of gcc, such functions and data would be emitted, but
 * would be warned about except with attribute((unused)).
 *
 * Mark functions that are referenced only in inline assembly as __used so
 * the code is emitted even though it appears to be unreferenced.
 */
/*
 * Rather then using noinline to prevent stack consumption, use
 * noinline_for_stack instead.  For documentaiton reasons.
 */
/*
 * From the GCC manual:
 *
 * Many functions do not examine any values except their arguments,
 * and have no effects except the return value.  Basically this is
 * just slightly more strict class than the `pure' attribute above,
 * since function is not allowed to read global memory.
 *
 * Note that a function that has pointer arguments and examines the
 * data pointed to must _not_ be declared `const'.  Likewise, a
 * function that calls a non-`const' function usually must not be
 * `const'.  It does not make sense for a `const' function to return
 * `void'.
 */
/*
 * Tell gcc if a function is cold. The compiler will assume any path
 * directly leading to the call is unlikely.
 */
/* Simple shorthand for a section definition */
/* Are two types/vars the same type (ignoring qualifiers)? */
/* Compile time object size, -1 for unknown */
/*
 * Prevent the compiler from merging or refetching accesses.  The compiler
 * is also forbidden from reordering successive instances of ACCESS_ONCE(),
 * but only when the compiler is aware of some particular ordering.  One way
 * to make the compiler aware of ordering is to put the two invocations of
 * ACCESS_ONCE() in different C statements.
 *
 * This macro does absolutely -nothing- to prevent the CPU from reordering,
 * merging, or refetching absolutely anything at any time.  Its main intended
 * use is to mediate communication between process-level code and irq/NMI
 * handlers, all running on the same CPU.
 */
/*
 * int-ll64 is used practically everywhere now,
 * so use it as a reasonable default.
 */
/*
 * asm-generic/int-ll64.h
 *
 * Integer declarations for architectures which use "long long"
 * for 64-bit types.
 */
/*
 * There seems to be no way of detecting this automatically from user
 * space, so 64 bit architectures should override this in their
 * bitsperlong.h. In particular, an architecture that supports
 * both 32 and 64 bit user space must not rely on CONFIG_64BIT
 * to decide it, but rather check a compiler provided macro.
 */
/*
 * FIXME: The check currently breaks x86-64 build, so it's
 * temporarily disabled. Please fix x86-64 and reenable
 */
/*
 * These aren't exported outside the kernel to avoid name space clashes
 */
/* const.h: Macros for dealing with constants.  */
/* Some constant macros are used in both assembler and
 * C code.  Therefore we cannot annotate them always with
 * 'UL' and other type specifiers unilaterally.  We
 * use the following macros to deal with this.
 *
 * Similarly, _AT() will cast an expression with a type in C, but
 * leave it unchanged in asm.
 */
/* PAGE_SHIFT determines the page size */
/* Cast PAGE_MASK to a signed type so that it is sign-extended if
   virtual addresses are 32-bits but physical addresses are larger
   (ie, 32-bit PAE). */
/*
 * Set __PAGE_OFFSET to the most negative possible address +
 * PGDIR_SIZE*16 (pgd slot 272).  The gap is to allow a space for a
 * hypervisor to fit.  Choosing 16 slots here is arbitrary, but it's
 * what Xen requires.
 */
/* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */
/*
 * Kernel image size is limited to 512 MB (see level2_kernel_pgt in
 * arch/x86/kernel/head_64.S), and it is mapped here:
 */
/*
 * low level task data that entry.S needs immediate access to
 * - this struct should fit entirely inside of one cache line
 * - this struct shares the supervisor stack pages
 */
/*
 * thread information flags
 * - these are process state flags that various assembly files
 *   may need to access
 * - pending work-to-be-done flags are in LSW
 * - other flags in MSW
 * Warning: layout of LSW is hardcoded in entry.S
 */
/* work to do in syscall_trace_enter() */
/* work to do in syscall_trace_leave() */
/* work to do on interrupt/exception return */
/* work to do on any return to user space */
/* Only used for 64 bit */
/* flags to check in __switch_to() */
/* thread information allocation */
/*
 * PER_CPU finds an address of a per-cpu variable.
 *
 * Args:
 *    var - variable name
 *    reg - 32bit register
 *
 * The resulting address is stored in the "reg" argument.
 *
 * Example:
 *    PER_CPU(cpu_gdt_descr, %ebx)
 */
/*
 * Define the "EARLY_PER_CPU" macros.  These are used for some per_cpu
 * variables that are initialized and accessed before there are per_cpu
 * areas allocated.
 */
/*
 * macros/functions for gaining access to the thread information structure
 * preempt_count needs to be 1 initially, until the scheduler is functional.
 */
/* how to get the thread information struct from ASM */
/*
 * Thread-synchronous status.
 *
 * This is different from the flags in that nobody else
 * ever touches our thread-synchronous status, so we don't
 * have to worry about atomic accesses.
 */
/* Indirect stringification.  Doing two levels allows the parameter to be a
 * macro itself.  For example, compile with -DFOO=bar, __stringify(FOO)
 * converts to "bar".
 */
/*
 * For assembly routines.
 *
 * Note when using these that you must specify the appropriate
 * alignment directives yourself
 */
/*
 * This is used by architectures to keep arguments on the stack
 * untouched by the compiler by keeping them live until the end.
 * The argument stack may be owned by the assembly-language
 * caller, not the callee, and gcc doesn't always understand
 * that.
 *
 * We have the return value, and a maximum of six arguments.
 *
 * This should always be followed by a "return ret" for the
 * protection to work (ie no more work that the compiler might
 * end up needing stack temporaries for).
 */
/* Assembly files may be compiled with -traditional .. */
/* If symbol 'name' is treated as a subroutine (gets called, and returns)
 * then please use ENDPROC to mark 'name' as STT_FUNC for the benefit of
 * static analysis tools such as stack depth analyzer.
 */
/* L1 cache line size */
/* Internal svga startup constants */
/* const.h: Macros for dealing with constants.  */
/* If _PAGE_BIT_PRESENT is clear, we use these: */
/* - if the user mapped it with PROT_NONE; pte_present gives true */
/* - set: nonlinear file mapping, saved PTE; unset:swap */
/* Set of bits not changed in pte_modify */
/*         xwr */
/*
 * early identity mapping  pte attrib macros.
 */
/*
 * PGDIR_SHIFT determines what a top-level page table entry can map
 */
/*
 * 3rd level page
 */
/*
 * PMD_SHIFT determines the size of the area a middle-level
 * page table can map
 */
/*
 * entries per page directory level
 */
/* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */
/* Physical address where kernel should be loaded. */
/* Minimum kernel alignment, as a power of two */
OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
OUTPUT_ARCH(i386:x86-64)
ENTRY(phys_startup_64)
jiffies_64 = jiffies;
/*
 * On 64-bit, align RODATA to 2MB so that even with CONFIG_DEBUG_RODATA
 * we retain large page mappings for boundaries spanning kernel text, rodata
 * and data sections.
 *
 * However, kernel identity mappings will have different RWX permissions
 * to the pages mapping to text and to the pages padding (which are freed) the
 * text section. Hence kernel identity mappings will be broken to smaller
 * pages. For 64-bit, kernel text and kernel identity mappings are different,
 * so we can enable protection checks that come with CONFIG_DEBUG_RODATA,
 * as well as retain 2MB large page mappings for kernel text.
 */
PHDRS {
 text PT_LOAD FLAGS(5); /* R_E */
 data PT_LOAD FLAGS(7); /* RWE */
 user PT_LOAD FLAGS(5); /* R_E */
 percpu PT_LOAD FLAGS(6); /* RW_ */
 init PT_LOAD FLAGS(7); /* RWE */
 note PT_NOTE FLAGS(0); /* ___ */
}
SECTIONS
{
        . = (0xffffffff80000000 + ((0x1000000 + (0x1000000 - 1)) & ~(0x1000000 - 1)));
        phys_startup_64 = startup_64 - 0xffffffff80000000;
 /* Text and read-only data */
 .text : AT(ADDR(.text) - 0xffffffff80000000) {
  _text = .;
  /* bootstrapping code */
  *(.head.text)
  . = ALIGN(8);
  _stext = .;
  . = ALIGN(8); *(.text.hot) *(.text) *(.ref.text) *(.devinit.text) *(.devexit.text) *(.cpuinit.text) *(.cpuexit.text) *(.text.unlikely)
  . = ALIGN(8); __sched_text_start = .; *(.sched.text) __sched_text_end = .;
  . = ALIGN(8); __lock_text_start = .; *(.spinlock.text) __lock_text_end = .;
  . = ALIGN(8); __kprobes_text_start = .; *(.kprobes.text) __kprobes_text_end = .;
 
  *(.fixup)
  *(.gnu.warning)
  /* End of text section */
  _etext = .;
 } :text = 0x9090
 .notes : AT(ADDR(.notes) - 0xffffffff80000000) { __start_notes = .; *(.note.*) __stop_notes = .; } :text :note
 . = ALIGN(16); __ex_table : AT(ADDR(__ex_table) - 0xffffffff80000000) { __start___ex_table = .; *(__ex_table) __stop___ex_table = .; } :text = 0x9090
 . = ALIGN((1 << 21));
 . = ALIGN(((1 << 12))); .rodata : AT(ADDR(.rodata) - 0xffffffff80000000) { __start_rodata = .; *(.rodata) *(.rodata.*) *(__vermagic) *(__markers_strings) *(__tracepoints_strings) } .rodata1 : AT(ADDR(.rodata1) - 0xffffffff80000000) { *(.rodata1) } . = ALIGN(8); __bug_table : AT(ADDR(__bug_table) - 0xffffffff80000000) { __start___bug_table = .; *(__bug_table) __stop___bug_table = .; } .pci_fixup : AT(ADDR(.pci_fixup) - 0xffffffff80000000) { __start_pci_fixups_early = .; *(.pci_fixup_early) __end_pci_fixups_early = .; __start_pci_fixups_header = .; *(.pci_fixup_header) __end_pci_fixups_header = .; __start_pci_fixups_final = .; *(.pci_fixup_final) __end_pci_fixups_final = .; __start_pci_fixups_enable = .; *(.pci_fixup_enable) __end_pci_fixups_enable = .; __start_pci_fixups_resume = .; *(.pci_fixup_resume) __end_pci_fixups_resume = .; __start_pci_fixups_resume_early = .; *(.pci_fixup_resume_early) __end_pci_fixups_resume_early = .; __start_pci_fixups_suspend = .; *(.pci_fixup_suspend) __end_pci_fixups_suspend = .; } .builtin_fw : AT(ADDR(.builtin_fw) - 0xffffffff80000000) { __start_builtin_fw = .; *(.builtin_fw) __end_builtin_fw = .; } .rio_route : AT(ADDR(.rio_route) - 0xffffffff80000000) { __start_rio_route_ops = .; *(.rio_route_ops) __end_rio_route_ops = .; } __ksymtab : AT(ADDR(__ksymtab) - 0xffffffff80000000) { __start___ksymtab = .; *(__ksymtab) __stop___ksymtab = .; } __ksymtab_gpl : AT(ADDR(__ksymtab_gpl) - 0xffffffff80000000) { __start___ksymtab_gpl = .; *(__ksymtab_gpl) __stop___ksymtab_gpl = .; } __ksymtab_unused : AT(ADDR(__ksymtab_unused) - 0xffffffff80000000) { __start___ksymtab_unused = .; *(__ksymtab_unused) __stop___ksymtab_unused = .; } __ksymtab_unused_gpl : AT(ADDR(__ksymtab_unused_gpl) - 0xffffffff80000000) { __start___ksymtab_unused_gpl = .; *(__ksymtab_unused_gpl) __stop___ksymtab_unused_gpl = .; } __ksymtab_gpl_future : AT(ADDR(__ksymtab_gpl_future) - 0xffffffff80000000) { __start___ksymtab_gpl_future = .; *(__ksymtab_gpl_future) __stop___ksymtab_gpl_future = .; } __kcrctab : AT(ADDR(__kcrctab) - 0xffffffff80000000) { __start___kcrctab = .; *(__kcrctab) __stop___kcrctab = .; } __kcrctab_gpl : AT(ADDR(__kcrctab_gpl) - 0xffffffff80000000) { __start___kcrctab_gpl = .; *(__kcrctab_gpl) __stop___kcrctab_gpl = .; } __kcrctab_unused : AT(ADDR(__kcrctab_unused) - 0xffffffff80000000) { __start___kcrctab_unused = .; *(__kcrctab_unused) __stop___kcrctab_unused = .; } __kcrctab_unused_gpl : AT(ADDR(__kcrctab_unused_gpl) - 0xffffffff80000000) { __start___kcrctab_unused_gpl = .; *(__kcrctab_unused_gpl) __stop___kcrctab_unused_gpl = .; } __kcrctab_gpl_future : AT(ADDR(__kcrctab_gpl_future) - 0xffffffff80000000) { __start___kcrctab_gpl_future = .; *(__kcrctab_gpl_future) __stop___kcrctab_gpl_future = .; } __ksymtab_strings : AT(ADDR(__ksymtab_strings) - 0xffffffff80000000) { *(__ksymtab_strings) } __init_rodata : AT(ADDR(__init_rodata) - 0xffffffff80000000) { *(.ref.rodata) *(.devinit.rodata) *(.devexit.rodata) *(.cpuinit.rodata) *(.cpuexit.rodata) } __param : AT(ADDR(__param) - 0xffffffff80000000) { __start___param = .; *(__param) __stop___param = .; . = ALIGN(((1 << 12))); __end_rodata = .; } . = ALIGN(((1 << 12)));
 . = ALIGN((1 << 21)); __end_rodata_hpage_align = .;
 /* Data */
 .data : AT(ADDR(.data) - 0xffffffff80000000) {
  /* Start of data section */
  _sdata = .;
  /* init_task */
  . = ALIGN(((1 << 12) << 1)); *(.data.init_task)
  . = ALIGN((1 << 12)); *(.data.page_aligned)
  . = ALIGN((1 << (6))); *(.data.cacheline_aligned)
  *(.data) *(.ref.data) *(.devinit.data) *(.devexit.data) *(.cpuinit.data) *(.cpuexit.data) . = ALIGN(8); __start___markers = .; *(__markers) __stop___markers = .; . = ALIGN(32); __start___tracepoints = .; *(__tracepoints) __stop___tracepoints = .; . = ALIGN(8); __start___verbose = .; *(__verbose) __stop___verbose = .; __start___trace_bprintk_fmt = .; *(__trace_printk_fmt) __stop___trace_bprintk_fmt = .; __start_ftrace_events = .; *(_ftrace_events) __stop_ftrace_events = .; __start_syscalls_metadata = .; *(__syscalls_metadata) __stop_syscalls_metadata = .;
  CONSTRUCTORS
  /* rarely changed data like cpu maps */
  . = ALIGN((1 << 6)); *(.data.read_mostly)
  /* End of data section */
  _edata = .;
 } :data
 . = ALIGN(4096);
 __vsyscall_0 = .;
 . = (-10*1024*1024);
 .vsyscall_0 : AT((ADDR(.vsyscall_0) - ((-10*1024*1024) - __vsyscall_0 + 0xffffffff80000000))) {
  *(.vsyscall_0)
 } :user
 . = ALIGN((1 << (6)));
 .vsyscall_fn : AT((ADDR(.vsyscall_fn) - ((-10*1024*1024) - __vsyscall_0 + 0xffffffff80000000))) {
  *(.vsyscall_fn)
 }
 . = ALIGN((1 << (6)));
 .vsyscall_gtod_data : AT((ADDR(.vsyscall_gtod_data) - ((-10*1024*1024) - __vsyscall_0 + 0xffffffff80000000))) {
  *(.vsyscall_gtod_data)
 }
 vsyscall_gtod_data = (ADDR(.vsyscall_gtod_data) - ((-10*1024*1024) - __vsyscall_0));
 .vsyscall_clock : AT((ADDR(.vsyscall_clock) - ((-10*1024*1024) - __vsyscall_0 + 0xffffffff80000000))) {
  *(.vsyscall_clock)
 }
 vsyscall_clock = (ADDR(.vsyscall_clock) - ((-10*1024*1024) - __vsyscall_0));
 .vsyscall_1 ADDR(.vsyscall_0) + 1024: AT((ADDR(.vsyscall_1) - ((-10*1024*1024) - __vsyscall_0 + 0xffffffff80000000))) {
  *(.vsyscall_1)
 }
 .vsyscall_2 ADDR(.vsyscall_0) + 2048: AT((ADDR(.vsyscall_2) - ((-10*1024*1024) - __vsyscall_0 + 0xffffffff80000000))) {
  *(.vsyscall_2)
 }
 .vgetcpu_mode : AT((ADDR(.vgetcpu_mode) - ((-10*1024*1024) - __vsyscall_0 + 0xffffffff80000000))) {
  *(.vgetcpu_mode)
 }
 vgetcpu_mode = (ADDR(.vgetcpu_mode) - ((-10*1024*1024) - __vsyscall_0));
 . = ALIGN((1 << (6)));
 .jiffies : AT((ADDR(.jiffies) - ((-10*1024*1024) - __vsyscall_0 + 0xffffffff80000000))) {
  *(.jiffies)
 }
 jiffies = (ADDR(.jiffies) - ((-10*1024*1024) - __vsyscall_0));
 .vsyscall_3 ADDR(.vsyscall_0) + 3072: AT((ADDR(.vsyscall_3) - ((-10*1024*1024) - __vsyscall_0 + 0xffffffff80000000))) {
  *(.vsyscall_3)
 }
 . = __vsyscall_0 + (1 << 12);
 /* Init code and data - will be freed after init */
 . = ALIGN((1 << 12));
 .init.begin : AT(ADDR(.init.begin) - 0xffffffff80000000) {
  __init_begin = .; /* paired with __init_end */
 }
 /*
	 * percpu offsets are zero-based on SMP.  PERCPU_VADDR() changes the
	 * output PHDR, so the next output section - .init.text - should
	 * start another segment - init.
	 */
 __per_cpu_load = .; .data.percpu 0 : AT(__per_cpu_load - 0xffffffff80000000) { __per_cpu_start = .; *(.data.percpu.first) *(.data.percpu.page_aligned) *(.data.percpu) *(.data.percpu.shared_aligned) __per_cpu_end = .; } :percpu . = __per_cpu_load + SIZEOF(.data.percpu);
 . = ALIGN((1 << 12)); .init.text : AT(ADDR(.init.text) - 0xffffffff80000000) { _sinittext = .; *(.init.text) *(.meminit.text) _einittext = .; }
 :init
 .init.data : AT(ADDR(.init.data) - 0xffffffff80000000) { *(.init.data) *(.meminit.data) . = ALIGN(8); __ctors_start = .; *(.ctors) __ctors_end = .; *(.init.rodata) *(.meminit.rodata) . = ALIGN(16); __setup_start = .; *(.init.setup) __setup_end = .; __initcall_start = .; *(.initcallearly.init) __early_initcall_end = .; *(.initcall0.init) *(.initcall0s.init) *(.initcall1.init) *(.initcall1s.init) *(.initcall2.init) *(.initcall2s.init) *(.initcall3.init) *(.initcall3s.init) *(.initcall4.init) *(.initcall4s.init) *(.initcall5.init) *(.initcall5s.init) *(.initcallrootfs.init) *(.initcall6.init) *(.initcall6s.init) *(.initcall7.init) *(.initcall7s.init) __initcall_end = .; __con_initcall_start = .; *(.con_initcall.init) __con_initcall_end = .; __security_initcall_start = .; *(.security_initcall.init) __security_initcall_end = .; . = ALIGN((1 << 12)); __initramfs_start = .; *(.init.ramfs) __initramfs_end = .; }
 .x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - 0xffffffff80000000) {
  __x86_cpu_dev_start = .;
  *(.x86_cpu_dev.init)
  __x86_cpu_dev_end = .;
 }
 . = ALIGN(8);
 .parainstructions : AT(ADDR(.parainstructions) - 0xffffffff80000000) {
  __parainstructions = .;
  *(.parainstructions)
  __parainstructions_end = .;
 }
 . = ALIGN(8);
 .altinstructions : AT(ADDR(.altinstructions) - 0xffffffff80000000) {
  __alt_instructions = .;
  *(.altinstructions)
  __alt_instructions_end = .;
 }
 .altinstr_replacement : AT(ADDR(.altinstr_replacement) - 0xffffffff80000000) {
  *(.altinstr_replacement)
 }
 /*
	 * .exit.text is discard at runtime, not link time, to deal with
	 *  references from .altinstructions and .eh_frame
	 */
 .exit.text : AT(ADDR(.exit.text) - 0xffffffff80000000) {
  *(.exit.text) *(.memexit.text)
 }
 .exit.data : AT(ADDR(.exit.data) - 0xffffffff80000000) {
  *(.exit.data) *(.memexit.data) *(.memexit.rodata)
 }
 . = ALIGN((1 << 12));
 /* freed after init ends here */
 .init.end : AT(ADDR(.init.end) - 0xffffffff80000000) {
  __init_end = .;
 }
 /*
	 * smp_locks might be freed after init
	 * start/end must be page aligned
	 */
 . = ALIGN((1 << 12));
 .smp_locks : AT(ADDR(.smp_locks) - 0xffffffff80000000) {
  __smp_locks = .;
  *(.smp_locks)
  . = ALIGN((1 << 12));
  __smp_locks_end = .;
 }
 .data_nosave : AT(ADDR(.data_nosave) - 0xffffffff80000000) {
  . = ALIGN((1 << 12)); __nosave_begin = .; *(.data.nosave) . = ALIGN((1 << 12)); __nosave_end = .;
 }
 /* BSS */
 . = ALIGN((1 << 12));
 .bss : AT(ADDR(.bss) - 0xffffffff80000000) {
  __bss_start = .;
  *(.bss.page_aligned)
  *(.bss)
  . = ALIGN(4);
  __bss_stop = .;
 }
 . = ALIGN((1 << 12));
 .brk : AT(ADDR(.brk) - 0xffffffff80000000) {
  __brk_base = .;
  . += 64 * 1024; /* 64k alignment slop space */
  *(.brk_reservation) /* areas brk users have reserved */
  __brk_limit = .;
 }
 _end = .;
        .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) }
        .debug 0 : { *(.debug) } .line 0 : { *(.line) } .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_sfnames 0 : { *(.debug_sfnames) } .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) }
 /* Sections to be discarded */
 /DISCARD/ : { *(.exit.text) *(.memexit.text) *(.exit.data) *(.memexit.data) *(.memexit.rodata) *(.exitcall.exit) *(.discard) }
 /DISCARD/ : { *(.eh_frame) }
}
/*
 * Per-cpu symbols which need to be offset from __per_cpu_load
 * for the boot processor.
 */
init_per_cpu__gdt_page = gdt_page + __per_cpu_load;
init_per_cpu__irq_stack_union = irq_stack_union + __per_cpu_load;
/*
 * Build-time check on the image size:
 */
. = ASSERT((_end - _text <= (512 * 1024 * 1024)),
    "kernel image bigger than KERNEL_IMAGE_SIZE");
. = ASSERT((irq_stack_union == 0),
           "irq_stack_union is not at start of per-cpu area");
. = ASSERT(kexec_control_code_size <= 2048,
           "kexec control code size is too big");

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Ian Lance Taylor]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> Linux kernel linker scripts needs to align .rodata section to 2MB:
>
> . = ALIGN((1 << 21));
>
> Since gold can only align to 4K, gold can't be used on Linux
> kernel.

gold can of course align to larger values.  That's why both GNU ld and
gold have the -z maxpagesize option.  Are the Linux kernel developers
willing to use that option?

Ian

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Ian Lance Taylor]

Török Edwin <edwintorok@gmail.com> writes:

> Should I open a bug and attach all these .o files too?

Sure, open a bug report at http://sourceware.org/bugzilla/ .  If you
are using a publically accessible version of the Linux kernel, you
don't need to attach the script or .o files.  Just put a link to the
kernel sources in the bug report, and any information about how you
configured and built it.

I don't know if the readelf differences you showed were for the
binutils 2.20 gold or the current gold.  There is no point to
reporting details about the 2.20 gold.

Ian

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[Török Edwin]

On 04/12/2010 08:47 PM, Ian Lance Taylor wrote:
> Török Edwin<edwintorok@gmail.com>  writes:
>
>> Should I open a bug and attach all these .o files too?
>
> Sure, open a bug report at http://sourceware.org/bugzilla/ .

Done, bug 11490, will attach some more info to it now.

> If you
> are using a publically accessible version of the Linux kernel, you
> don't need to attach the script or .o files.  Just put a link to the
> kernel sources in the bug report, and any information about how you
> configured and built it.

Ok.

>
> I don't know if the readelf differences you showed were for the
> binutils 2.20 gold or the current gold.  There is no point to
> reporting details about the 2.20 gold.

I don't know either, I'll redo the diff with exactly the config I 
described in the bugreport.

Best regards,
--Edwin