"m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)

"m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)

[Geert Uytterhoeven]

On Sun, Jan 10, 2010 at 05:56, Michael Schmitz
<schmitz@biophys.uni-duesseldorf.de> wrote:
>> > > I'll verify that on the new tree, and start bisecting. Sigh.
>> >
>> > Good luck!
>>
>> 7c5fd5619dc89fb52d2c2cf144fc6e4365427b86 is first bad commit
>> commit 7c5fd5619dc89fb52d2c2cf144fc6e4365427b86
>> Author: Tim Abbott <tabbott@ksplice.com>
>> Date:   Sun Sep 27 13:57:55 2009 -0400
>>
>>     m68k: Cleanup linker scripts using new linker script macros.
>>
>>     Signed-off-by: Tim Abbott <tabbott@ksplice.com>
>>     Tested-by: Andreas Schwab <schwab@linux-m68k.org>
>>     Cc: Roman Zippel <zippel@linux-m68k.org>
>>     Cc: Sam Ravnborg <sam@ravnborg.org>
>>     Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>
>> :040000 040000 5bdbf7ce5dd4ea2f23669c6a6ec11192865b5bfa
>> d3b7397533b0af6261747ccef3cff9cd40f6baf9 M    arch
>
> Backing out that commit on the top of the tree results in a bootable
> 2.6.33-rc2 for me
>
> The order of symbols in the system map is different (as you would expect)
> but I don't see what implicit assumption would be violated.

Tim, any clues? Michael is using gcc 3.3.6 and binutils 2.16.
It works fine with my 4.1.2/2.18 vombo.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On Sun, Jan 10, 2010 at 05:56, Michael Schmitz
> <schmitz@biophys.uni-duesseldorf.de> wrote:
>>> > > I'll verify that on the new tree, and start bisecting. Sigh.
>>> >
>>> > Good luck!
>>>
>>> 7c5fd5619dc89fb52d2c2cf144fc6e4365427b86 is first bad commit
>>> commit 7c5fd5619dc89fb52d2c2cf144fc6e4365427b86
>>> Author: Tim Abbott <tabbott@ksplice.com>
>>> Date:   Sun Sep 27 13:57:55 2009 -0400
>>>
>>>     m68k: Cleanup linker scripts using new linker script macros.
>>>
>>>     Signed-off-by: Tim Abbott <tabbott@ksplice.com>
>>>     Tested-by: Andreas Schwab <schwab@linux-m68k.org>
>>>     Cc: Roman Zippel <zippel@linux-m68k.org>
>>>     Cc: Sam Ravnborg <sam@ravnborg.org>
>>>     Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>>
>>> :040000 040000 5bdbf7ce5dd4ea2f23669c6a6ec11192865b5bfa
>>> d3b7397533b0af6261747ccef3cff9cd40f6baf9 M    arch
>>
>> Backing out that commit on the top of the tree results in a bootable
>> 2.6.33-rc2 for me
>>
>> The order of symbols in the system map is different (as you would expect)
>> but I don't see what implicit assumption would be violated.
>
> Tim, any clues? Michael is using gcc 3.3.6 and binutils 2.16.
> It works fine with my 4.1.2/2.18 vombo.

Most likely an alignment issue so that the bootinfo structure is not
found.  At least that was the issue with previous incarnations of the
patch.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)

[Tim Abbott]

On Sun, 10 Jan 2010, Geert Uytterhoeven wrote:

> On Sun, Jan 10, 2010 at 05:56, Michael Schmitz
> <schmitz@biophys.uni-duesseldorf.de> wrote:
> > Backing out that commit on the top of the tree results in a bootable
> > 2.6.33-rc2 for me
> >
> > The order of symbols in the system map is different (as you would expect)
> > but I don't see what implicit assumption would be violated.
> 
> Tim, any clues? Michael is using gcc 3.3.6 and binutils 2.16.
> It works fine with my 4.1.2/2.18 vombo.

I think to debug this, we'll want to split the patch into the various 
small changes that make it up and determine which change caused the 
problem.  Michael, are you willing to do that debugging?  I'd be happy to 
generate for you a patch series of like a dozen patches broken out for 
bisecting if that'd help.

	-Tim Abbott

Re: "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)

[Michael Schmitz]

Hi Tim,

> > > The order of symbols in the system map is different (as you would expect)
> > > but I don't see what implicit assumption would be violated.
> > 
> > Tim, any clues? Michael is using gcc 3.3.6 and binutils 2.16.
> > It works fine with my 4.1.2/2.18 vombo.
> 
> I think to debug this, we'll want to split the patch into the various 
> small changes that make it up and determine which change caused the 
> problem.  Michael, are you willing to do that debugging?  I'd be happy to 
> generate for you a patch series of like a dozen patches broken out for 
> bisecting if that'd help.

Forgot to mention - I did (manually) revert the patch by pieces (throwing out
the macros and putting back the code that was replaced by the macros). Nothiing 
short of a complete reversal would fix the problem.

Seeing as I'm not a toolchain expert, I may have made mistakes in dissecting
the patch. If you can send a series of patches I'd be happy to test them (just 
tell me whether they're all relative to git head, or need to be applied strictly 
in order). 

Absence or misplacement of bootinfo data as suggested by Andreas seems a good 
candidate - here's the symbols that are explicitly mentioned in the old LD 
script, for the new (non-booting) kernel:

00001000 A _text
00002000 T _start
00212dc6 A _etext
00212dd0 R __start___ex_table
00215590 R __stop___ex_table
002f0d14 A _edata
002f1000 A __init_begin
002f1000 T _sinittext
0030610e T _einittext
0030aa80 T __setup_start
0030ad14 T __initcall_start
0030ad14 T __setup_end
0030afcc T __con_initcall_start
0030afcc T __initcall_end
0030afd0 T __con_initcall_end
0030b000 T __initramfs_start
0030b200 D __start_fixup
0030b200 T __initramfs_end
0030bed0 D __stop_fixup
0030c000 A _end
0030c000 T __init_end

And this is the same list for the kernel generated using the old LD script:

00001000 A _text
00002000 T _start
00212dc6 A _etext
00212dd0 A __start___ex_table
00215590 A __stop___ex_table
002edd14 A _edata
002ee000 A __init_begin
002ee000 T _sinittext
0030310e T _einittext
00307a80 A __setup_start
00307d14 A __initcall_start
00307d14 A __setup_end
00307fcc A __con_initcall_start
00307fcc A __initcall_end
00307fd0 A __con_initcall_end
00307fd0 D __start_fixup
00308ca0 D __stop_fixup
0030a000 A __initramfs_start
0030a200 A __initramfs_end
0030c000 A __init_end
0030e000 A _end

The only difference I can spot is the placement of the fixup section.

FWIW: when stripping the new kernel, I get this warning:

BFD: st7CwWnM: warning: allocated section `.init_end' not in segment

And indeed, the old script places the init task data between .init_end and _end.

Binutils bug, or meaningless? 

	Michael

Re: "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)

[Andreas Schwab]

Michael Schmitz <schmitz@biophys.uni-duesseldorf.de> writes:

> And indeed, the old script places the init task data between .init_end and _end.

This is exactly your problem.  The bootloader puts the bootinfo
structure at _end, and the kernel reads it from there.  But in your
non-working kernel that overlaps the init task structure.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)

[Andreas Schwab]

Michael Schmitz <schmitz@biophys.uni-duesseldorf.de> writes:

> FWIW: when stripping the new kernel, I get this warning:
>
> BFD: st7CwWnM: warning: allocated section `.init_end' not in segment

This is actually your problem.  The .init_end section is kind of special
because it only contains an ALIGN.  What do you get from running
"readelf -l vmlinux"?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)

[Michael Schmitz]

Hi Andreas,

> > FWIW: when stripping the new kernel, I get this warning:
> >
> > BFD: st7CwWnM: warning: allocated section `.init_end' not in segment
> 
> This is actually your problem.  The .init_end section is kind of special
> because it only contains an ALIGN.  What do you get from running
> "readelf -l vmlinux"?

Current LD script:
schmitz@xplor:/org/kernel/linux2.6-m68k-git/linux-m68k$ readelf -l 
vmlinux-newlds

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

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x2d3240 0x2f0d14 RWE 0x2000
  LOAD           0x2d5000 0x002f1000 0x002f1000 0x1aed0 0x1aed0 RWE 0x2000

 Section to Segment mapping:
  Segment Sections...
   00     .text __ex_table .rodata __ksymtab __ksymtab_gpl __ksymtab_strings __param .data .bss 
   01     .init.text .init.data .m68k_fixup 

Old (working) LD script:

schmitz@xplor:/org/kernel/linux2.6-m68k-git/linux-m68k$ readelf -l 
vmlinux-oldlds

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

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x2d0240 0x2edd14 RWE 0x2000
  LOAD           0x2d2000 0x002ee000 0x002ee000 0x20000 0x20000 RWE 0x2000

 Section to Segment mapping:
  Segment Sections...
   00     .text __ex_table .rodata __ksymtab __ksymtab_gpl __ksymtab_strings __param .data .bss 
   01     .init.text .init.data .init.setup .initcall.init .con_initcall.init .m68k_fixup .init.ramfs .data.init_task 

Looks like the size of the BSS segment is not aligned in the broken case. 

Putting this into the script:

--- arch/m68k/kernel/vmlinux-std.lds.org	2010-01-09 11:01:05.000000000 
+1300
+++ arch/m68k/kernel/vmlinux-std.lds	2010-01-11 09:40:24.000000000 +1300
@@ -51,6 +51,10 @@
 	__init_end = .;
   }
 
+  . = . + 0x1000;
+
+  . = ALIGN(8192);
+
   _end = . ;
 
   STABS_DEBUG

does place both __init_end and _end on separate aligned boundaries but leaves
the end of the actual BSS unaligned. 

Geert's kernel has this readelf output:

schmitz@xplor:/org/m68k/aranym$ readelf -l 
vmlinux-2.6.33-rc2-atari-00203-gdd8abd9

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

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x2de440 0x2fb450 RWE 0x2000
  LOAD           0x2e0000 0x002fc000 0x002fc000 0x1cf4c 0x1d000 RWE 0x2000

 Section to Segment mapping:
  Segment Sections...
   00     .text __ex_table .rodata __ksymtab __ksymtab_gpl __ksymtab_strings __param .data .bss 
   01     .init.text .init.data .m68k_fixup .notes .init_end 

The end of the BSS in memory is aligned here. 

What is needed in the script to force this alignment? How do I place a null byte 
right at __init_end ?? 

Thanks,

	Michael

Re: "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)

[Michael Schmitz]

Hi Andreas,

> > FWIW: when stripping the new kernel, I get this warning:
> >
> > BFD: st7CwWnM: warning: allocated section `.init_end' not in segment
> 
> This is actually your problem.  The .init_end section is kind of special
> because it only contains an ALIGN.  What do you get from running
> "readelf -l vmlinux"?

Followup on this: You are absolutely right - the problem appears to be related 
to the the .init_end section _only_ having the ALIGN, and nothing else (i.e. 
no actual section content). 

Placing the align in the .m68k_fixup section like such:

--- arch/m68k/kernel/vmlinux-std.lds.org	2010-01-09 11:01:05.000000000 
+1300
+++ arch/m68k/kernel/vmlinux-std.lds	2010-01-12 08:43:07.000000000 +1300
@@ -42,6 +42,7 @@
 	__start_fixup = .;
 	*(.m68k_fixup)
 	__stop_fixup = .;
+        . = ALIGN(PAGE_SIZE);
   }
   NOTES
   .init_end : {

still puts .init_end, __init_end and _end on a page boundary, but also extends
the load section up to that page boundary. (Unfortunately, it also extends the 
kernel file size by a bit). 

Can the same be achieved in a more elegant way? The reason why the old script 
worked with my binutils appears to be the placement of the initramfs data right 
at the end - the start of initramfs is page aligned, and the size of the 
initramfs is an integer number of pages, so the end of initramfs data, 
__init_end and _end all are on a page boundary. With the fixup section now 
placed after the initramfs explicitly, this no longer happens by accident...

Cheers,

	Michael

Re: "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)

[Tim Abbott]

Has this fix been merged yet?  It seems to me that the patch Michael sent 
is a totally reasonable solution to this problem, and I had assumed that 
it was going to get picked up in the m68k tree when I saw this patch 2 
months ago...

	-Tim Abbott

On Mon, 11 Jan 2010, Michael Schmitz wrote:

> Followup on this: You are absolutely right - the problem appears to be related 
> to the the .init_end section _only_ having the ALIGN, and nothing else (i.e. 
> no actual section content). 
> 
> Placing the align in the .m68k_fixup section like such:
> 
> --- arch/m68k/kernel/vmlinux-std.lds.org	2010-01-09 11:01:05.000000000 
> +1300
> +++ arch/m68k/kernel/vmlinux-std.lds	2010-01-12 08:43:07.000000000 +1300
> @@ -42,6 +42,7 @@
>  	__start_fixup = .;
>  	*(.m68k_fixup)
>  	__stop_fixup = .;
> +        . = ALIGN(PAGE_SIZE);
>    }
>    NOTES
>    .init_end : {
> 
> still puts .init_end, __init_end and _end on a page boundary, but also extends
> the load section up to that page boundary. (Unfortunately, it also extends the 
> kernel file size by a bit). 
> 
> Can the same be achieved in a more elegant way? The reason why the old script 
> worked with my binutils appears to be the placement of the initramfs data right 
> at the end - the start of initramfs is page aligned, and the size of the 
> initramfs is an integer number of pages, so the end of initramfs data, 
> __init_end and _end all are on a page boundary. With the fixup section now 
> placed after the initramfs explicitly, this no longer happens by accident...
> 
> Cheers,
> 
> 	Michael
> 
> 
> 

Re: "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)

[Michael Schmitz]

Hi Tim,

On Sun, 7 Mar 2010, Tim Abbott wrote:

> Has this fix been merged yet?  It seems to me that the patch Michael sent 
> is a totally reasonable solution to this problem, and I had assumed that 
> it was going to get picked up in the m68k tree when I saw this patch 2 
> months ago...
> 
> 	-Tim Abbott

This hadn't been picked up last time I tried (at least two weeks back). Can't 
really speak to the current state, as I've juyt lost all of the last half 
year's worth of work due to a disk crash caused by Genesis Energy incompetently 
upgrading power meters in Auckland.

I never complained because it really is only a problem with my broken version of 
the cross toolchain. I'll make a fresh effort with the toolchain now. 

Cheers,

  Michael


> 
> On Mon, 11 Jan 2010, Michael Schmitz wrote:
> 
> > Followup on this: You are absolutely right - the problem appears to be related 
> > to the the .init_end section _only_ having the ALIGN, and nothing else (i.e. 
> > no actual section content). 
> > 
> > Placing the align in the .m68k_fixup section like such:
> > 
> > --- arch/m68k/kernel/vmlinux-std.lds.org	2010-01-09 11:01:05.000000000 
> > +1300
> > +++ arch/m68k/kernel/vmlinux-std.lds	2010-01-12 08:43:07.000000000 +1300
> > @@ -42,6 +42,7 @@
> >  	__start_fixup = .;
> >  	*(.m68k_fixup)
> >  	__stop_fixup = .;
> > +        . = ALIGN(PAGE_SIZE);
> >    }
> >    NOTES
> >    .init_end : {
> > 
> > still puts .init_end, __init_end and _end on a page boundary, but also extends
> > the load section up to that page boundary. (Unfortunately, it also extends the 
> > kernel file size by a bit). 
> > 
> > Can the same be achieved in a more elegant way? The reason why the old script 
> > worked with my binutils appears to be the placement of the initramfs data right 
> > at the end - the start of initramfs is page aligned, and the size of the 
> > initramfs is an integer number of pages, so the end of initramfs data, 
> > __init_end and _end all are on a page boundary. With the fixup section now 
> > placed after the initramfs explicitly, this no longer happens by accident...
> > 
> > Cheers,
> > 
> > 	Michael
> > 
> > 
> > 
>