linux-kernel - Re: "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-id: <alpine.DEB.2.00.1003270801090.20795@zirkon.biophys.uni-duesseldorf.de>
Date:	Sat, 27 Mar 2010 08:13:16 +0100 (CET)
From:	Michael Schmitz <schmitz@...phys.uni-duesseldorf.de>
To:	Tim Abbott <tabbott@...lice.com>
Cc:	Andreas Schwab <schwab@...ux-m68k.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	linux-m68k@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: 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)

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
> > 
> > 
> > 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/