From: Sam Ravnborg <sam@ravnborg.org>
To: Mike Galbraith <efault@gmx.de>
Cc: Mikael Pettersson <mikpe@csd.uu.se>,
kai@tp1.ruhr-uni-bochum.de, rusty@rustcorp.com.au,
linux-kernel@vger.kernel.org
Subject: Re: 2.5.59 vmlinux.lds.S change broke modules
Date: Sat, 18 Jan 2003 10:23:31 +0100 [thread overview]
Message-ID: <20030118092331.GA1483@mars.ravnborg.org> (raw)
In-Reply-To: <5.1.1.6.2.20030118085515.00c99e40@pop.gmx.net>
On Sat, Jan 18, 2003 at 09:00:51AM +0100, Mike Galbraith wrote:
> At 01:55 PM 1/17/2003 +0100, Mikael Pettersson wrote:
>
> >Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> >problem and modules now load correctly for me.
>
> Hi,
>
> Putting . = ALIGN(64) back in front of __start___ksymtab = .
> (vmlinux.lds.h) fixed it here.
But that is just a way to hide the real problem.
With . = ALIGN(64);
you make sure that the linker does not do any alignment of .
when entering the section.
It is much better to let the linker do proper alignment, and not
to rely on a magic number in the .lds file.
Now consider if we decide to put in a new symbol with alignment 128 for
some reason. A little gcc magic is used to sepecy the alignment of
the symbol, but the resulting kernel oopses. Why?
Because the ALIGN() preceeding the section was not adjusted properly.
Only sane way is to move the labels inside the block, or at least let
them depend on the address of the section. The lables should not
be assigned the value of ., when we know the linker may adjust it.
The solution that Russell used for ARM is IMO the best way to do it.
The only issue remaining here is what the linker will do for an empty
section, as Eric points out. I have not investigated that.
Sam
next prev parent reply other threads:[~2003-01-18 9:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-17 12:55 2.5.59 vmlinux.lds.S change broke modules Mikael Pettersson
2003-01-17 13:44 ` Brian Gerst
2003-01-17 13:49 ` Mikael Pettersson
2003-01-17 14:32 ` Mike Galbraith
2003-01-17 13:56 ` Russell King
2003-01-17 16:13 ` Eric W. Biederman
2003-01-17 16:21 ` Sam Ravnborg
2003-01-18 3:08 ` Eric W. Biederman
2003-01-17 16:24 ` Kai Germaschewski
2003-01-17 16:50 ` Russell King
2003-01-17 16:19 ` Sam Ravnborg
2003-01-17 14:44 ` Kai Germaschewski
2003-01-18 0:11 ` Kai Germaschewski
2003-01-18 5:45 ` Christopher Faylor
2003-01-18 6:14 ` J Sloan
2003-01-18 8:00 ` Mike Galbraith
2003-01-18 9:23 ` Sam Ravnborg [this message]
2003-01-18 9:34 ` Mike Galbraith
[not found] ` <Pine.LNX.4.44.0301171808010.15056-100000@chaos.physics.uio wa.edu>
2003-01-18 9:07 ` Mike Galbraith
-- strict thread matches above, loose matches on Subject: below --
2003-01-17 13:27 Adam J. Richter
2003-01-18 14:36 Mikael Pettersson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030118092331.GA1483@mars.ravnborg.org \
--to=sam@ravnborg.org \
--cc=efault@gmx.de \
--cc=kai@tp1.ruhr-uni-bochum.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@csd.uu.se \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox