On Sun, Jan 10, 2010 at 05:56, Michael Schmitz
<[email protected]> 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 <[email protected]>
>> Date: Sun Sep 27 13:57:55 2009 -0400
>>
>> m68k: Cleanup linker scripts using new linker script macros.
>>
>> Signed-off-by: Tim Abbott <[email protected]>
>> Tested-by: Andreas Schwab <[email protected]>
>> Cc: Roman Zippel <[email protected]>
>> Cc: Sam Ravnborg <[email protected]>
>> Signed-off-by: Geert Uytterhoeven <[email protected]>
>>
>> :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 -- [email protected]
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
Geert Uytterhoeven <[email protected]> writes:
> On Sun, Jan 10, 2010 at 05:56, Michael Schmitz
> <[email protected]> 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 <[email protected]>
>>> Date: Sun Sep 27 13:57:55 2009 -0400
>>>
>>> m68k: Cleanup linker scripts using new linker script macros.
>>>
>>> Signed-off-by: Tim Abbott <[email protected]>
>>> Tested-by: Andreas Schwab <[email protected]>
>>> Cc: Roman Zippel <[email protected]>
>>> Cc: Sam Ravnborg <[email protected]>
>>> Signed-off-by: Geert Uytterhoeven <[email protected]>
>>>
>>> :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, [email protected]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Sun, 10 Jan 2010, Geert Uytterhoeven wrote:
> On Sun, Jan 10, 2010 at 05:56, Michael Schmitz
> <[email protected]> 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
Michael Schmitz <[email protected]> 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, [email protected]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Michael Schmitz <[email protected]> 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, [email protected]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
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
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
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