lkml.org 
[lkml]   [2010]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: "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)
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
>
>
>


\
 
 \ /
  Last update: 2010-03-07 19:41    [W:0.078 / U:2.460 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site