All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: PARISC list <parisc-linux@lists.parisc-linux.org>
Subject: Re: [parisc-linux] kernel module relocation bug
Date: 29 Nov 2004 19:18:51 -0600	[thread overview]
Message-ID: <1101777536.2114.103.camel@mulgrave> (raw)
In-Reply-To: <200411300023.iAU0NaI2014797@hiauly1.hia.nrc.ca>

On Mon, 2004-11-29 at 18:23, John David Anglin wrote:
> > On Mon, 2004-11-29 at 18:08, John David Anglin wrote:
> > > With -ffunction-sections, gcc guarantees that calls can reach the
> > > beginning of a function plus some margin for the stub table.  The linker
> > > inserts stubs on a per function basis.  This should work better with
> > > relinking as the functions remain in their own sections.
> > 
> > So what we really need is the equivalent of -ffunction-sections for the
> > linker where, when we combine a bunch of .o's it sees if the branches
> > are getting too far a way and drops a stub in between the function
> > sections (so that the in-kernel linker doesn't have to bother about
> > doing this).
> 
> Then, in the final or in-kernel link, the long branch stubs get
> fixed.

That's the general idea.  Obviously any two pass linker (like the one in
binutils) can place the stubs optimally in between the sections (as long
as the code was compiled with -ffunction-sections) as part of the final
link, but the in-kernel linker is small and simple and I'd rather not
have to introduce it to the concept of multiple passes, so if there were
a flag to get binutils to do the hard work for us it would be much
appreciated.

James


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

      reply	other threads:[~2004-11-30  1:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-27  6:47 [parisc-linux] kernel module relocation bug Randolph Chung
2004-11-29 15:32 ` James Bottomley
2004-11-29 15:33 ` James Bottomley
2004-11-29 19:27   ` Ulrich Teichert
2004-11-29 19:46     ` Randolph Chung
2004-11-29 22:51       ` Ulrich Teichert
2004-11-29 23:46         ` John David Anglin
2004-12-02 21:54           ` [parisc-linux] Userland relocation problems resolved (was: kernel module relocation bug) Ulrich Teichert
2004-12-02 22:51             ` [parisc-linux] Re: Userland relocation problems resolved (was: kernel module relocat John David Anglin
2004-11-29 23:53 ` [parisc-linux] kernel module relocation bug John David Anglin
2004-11-29 23:54   ` Randolph Chung
2004-11-29 23:57   ` Randolph Chung
2004-11-30  0:08     ` John David Anglin
2004-11-30  0:11       ` James Bottomley
2004-11-30  0:23         ` John David Anglin
2004-11-30  1:18           ` James Bottomley [this message]

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=1101777536.2114.103.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=parisc-linux@lists.parisc-linux.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.