public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs
Date: Thu, 08 May 2003 02:16:29 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590723705675@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590723705550@msgid-missing>

On Wed, 7 May 2003 17:23:31 -0700, 
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>>>>>> On Wed, 7 May 2003 17:21:18 -0700, David Mosberger <davidm@linux.hpl.hp.com> said:
>
>>>>>> On Wed, 7 May 2003 17:00:45 -0700, Jesse Barnes <jbarnes@sgi.com> said:
>  Jesse> Ahh, this might be a good way to go.  We'd basically be
>  Jesse> relinking the kernel at load time with a new KERNEL_START,
>  Jesse> right?
>
>  David> Yup.
>
>On second thought, "relinking" might be confusing.  "Relocating" is
>more accurate (we don't rearrange anything within the kernel, just
>moving the whole thing around, which is a lot easier).

Using what data?  vmlinux does not contain any relocation data,
everything is converted to absolute addresses in the the final link
stage.  If you only use standard ld output then elilo will have to
handle all the relocations, messy.

One possibility is to link vmlinux to a temporary file, using -r to
preserve the relocation data, followed by a link to the real vmlinux,
without -r.  From the temporary file, extract the information that is
required to perform boot time relocation and append that data to vmlinux,
at _end.  The kernel startup code (PIC assembler) runs the additional
table, adjusts the relocations then discards the table.

A quick check of a 2.4 ia64 kernel shows only these relocation types:

DIR32LSB
DIR64LSB
FPTR64LSB
GPREL22
IMM64
LTOFF22
LTOFF_FPTR22
PCREL21B
PCREL60B
SEGREL64LSB

GPREL22, LTOFF22, LTOFF_FPTR22, PCREL21B, PCREL60B, SEGREL64LSB are not
a problem, they are already PIC.  DIR32LSB, DIR64LSB, FPTR64LSB are
easy to adjust.  IMM64 is the only messy bit of code, lots of shifts.
Even IMM64 is not that hard to do in PIC asm.

This approach keeps all the kernel relocation code inside the ia64
tree, it does not rely on keeping elilo in sync with future kernel
and/or gcc changes.  By extracting and formatting the relocation data
at build time, it simplifies and speeds up the load process.



  parent reply	other threads:[~2003-05-08  2:16 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-17 23:05 [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs David Mosberger
2003-04-17 23:57 ` Jesse Barnes
2003-04-25 21:02 ` Jesse Barnes
2003-05-07 22:39 ` David Mosberger
2003-05-07 23:24 ` Luck, Tony
2003-05-07 23:51 ` David Mosberger
2003-05-08  0:00 ` Jesse Barnes
2003-05-08  0:04 ` Jesse Barnes
2003-05-08  0:07 ` Luck, Tony
2003-05-08  0:13 ` Keith Owens
2003-05-08  0:21 ` David Mosberger
2003-05-08  0:23 ` David Mosberger
2003-05-08  0:24 ` Keith Owens
2003-05-08  0:54 ` David Mosberger
2003-05-08  1:07 ` David Mosberger
2003-05-08  1:46 ` Jesse Barnes
2003-05-08  1:55 ` Keith Owens
2003-05-08  2:16 ` Keith Owens [this message]
2003-05-08  4:59 ` David Mosberger
2003-05-08 16:07 ` Jesse Barnes
2003-05-08 17:07 ` David Mosberger
2003-05-08 17:20 ` Jesse Barnes
2003-05-08 17:50 ` David Mosberger
2003-05-08 17:54 ` Luck, Tony
2003-05-08 20:29 ` David Mosberger
2003-05-08 22:17 ` Keith Owens
2003-05-08 22:27 ` Luck, Tony
2003-05-08 22:31 ` Jesse Barnes
2003-05-08 22:53 ` David Mosberger
2003-05-08 23:32 ` David Mosberger
2003-05-09  0:01 ` Jesse Barnes
2003-05-09  0:11 ` Jesse Barnes
2003-05-09 17:52 ` Jesse Barnes
2003-05-09 18:25 ` David Mosberger
2003-05-09 19:30 ` Jesse Barnes
2003-05-09 19:31 ` Jack Steiner
2003-05-09 20:02 ` Jack Steiner
2003-05-09 20:25 ` David Mosberger
2003-05-09 21:43 ` Luck, Tony
2003-05-10  2:39 ` Jack Steiner
2003-05-13 22:18 ` Luck, Tony
2003-05-14  1:24 ` Jesse Barnes
2003-05-14  5:29 ` Christian Hildner
2003-05-14 16:44 ` Luck, Tony
2003-05-15  3:05 ` David Mosberger
2003-05-15 16:33 ` Luck, Tony
2003-05-15 18:03 ` Jack Steiner
2003-05-15 18:59 ` David Mosberger
2003-05-15 21:43 ` Luck, Tony
2003-05-16 22:33 ` Luck, Tony
2003-05-16 22:47 ` David Mosberger
2003-05-16 22:54 ` [Linux-ia64] " Luck, Tony
2003-05-16 22:58 ` David Mosberger
2003-05-19 17:57 ` Luck, Tony
2003-05-19 18:02 ` Jesse Barnes
2003-05-19 18:39 ` David Mosberger
2003-05-19 19:07 ` Luck, Tony
2003-05-28 19:10 ` Luck, Tony
2003-05-28 20:05 ` Luck, Tony
2003-05-28 20:13 ` Luck, Tony

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=marc-linux-ia64-105590723705675@msgid-missing \
    --to=kaos@ocs.com.au \
    --cc=linux-ia64@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox