public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: vgoyal@in.ibm.com
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Reloc Kernel List <fastboot@lists.osdl.org>,
	ebiederm@xmission.com, ak@suse.de, horms@verge.net.au,
	lace@jankratochvil.net, hpa@zytor.com, magnus.damm@gmail.com,
	lwang@redhat.com, dzickus@redhat.com, maneesh@in.ibm.com
Subject: Re: [PATCH 1/12] i386: Distinguish absolute symbols
Date: Fri, 6 Oct 2006 23:35:47 -0700	[thread overview]
Message-ID: <20061006233547.43888a48.akpm@osdl.org> (raw)
In-Reply-To: <20061003170413.GA3164@in.ibm.com>

On Tue, 3 Oct 2006 13:04:13 -0400
Vivek Goyal <vgoyal@in.ibm.com> wrote:

> Ld knows about 2 kinds of symbols,  absolute and section
> relative.  Section relative symbols symbols change value
> when a section is moved and absolute symbols do not.
> 
> Currently in the linker script we have several labels
> marking the beginning and ending of sections that
> are outside of sections, making them absolute symbols.
> Having a mixture of absolute and section relative
> symbols refereing to the same data is currently harmless
> but it is confusing.
> 
> This must be done carefully as newer revs of ld do not place
> symbols that appear in sections without data and instead
> ld makes those symbols global :(
> 
> My ultimate goal is to build a relocatable kernel.  The
> safest and least intrusive technique is to generate
> relocation entries so the kernel can be relocated at load
> time.  The only penalty would be an increase in the size
> of the kernel binary.  The problem is that if absolute and
> relocatable symbols are not properly specified absolute symbols
> will be relocated or section relative symbols won't be, which
> is fatal.
> 
> The practical motivation is that when generating kernels that
> will run from a reserved area for analyzing what caused
> a kernel panic, it is simpler if you don't need to hard code
> the physical memory location they will run at, especially
> for the distributions.

This patch causes the following warnings:

/opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-ld: .tmp_vmlinux1: warning: allocated section `.smp_altinstr_replacement' not in segment
/opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-ld: .tmp_vmlinux2: warning: allocated section `.smp_altinstr_replacement' not in segment
/opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-ld: vmlinux: warning: allocated section `.smp_altinstr_replacement' not in segment

The patch
i386-force-section-size-to-be-non-zero-to-prevent-a-symbol-becoming-absolute.patch
makes those warnings go away again, but we decided to drop that.

This:

  .smp_altinstr_replacement : AT(ADDR(.smp_altinstr_replacement) - LOAD_OFFSET) {
	*(.smp_altinstr_replacement)
	. = ALIGN(4096);
	__smp_alt_end = .;
  }

looks odd.  What's the point in putting a gap before __smp_alt_end?  Moving
__smp_alt_end to before the ALIGN doesn't prevent the warning.

GNU ld version 2.16.1, gcc-4.1.0, config at
http://userweb.kernel.org/~akpm/config-vmm.txt


  reply	other threads:[~2006-10-07  6:36 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-03 17:00 [RFC][PATCH 0/12] ELF Relocatable x86 bzImage (V2) Vivek Goyal
2006-10-03 17:04 ` [PATCH 1/12] i386: Distinguish absolute symbols Vivek Goyal
2006-10-07  6:35   ` Andrew Morton [this message]
2006-10-08 16:47     ` Vivek Goyal
2006-10-09  7:35       ` Gerd Hoffmann
2006-10-09 13:49         ` Vivek Goyal
2006-10-03 17:06 ` [PATCH 2/12] i386: align data section to 4K boundary Vivek Goyal
2006-10-04 11:17   ` Andi Kleen
2006-10-04 15:18     ` H. Peter Anvin
2006-10-03 17:09 ` [PATCH 3/12] i386: Force section size to be non-zero to prevent a symbol becoming absolute Vivek Goyal
2006-10-04 11:02   ` Andi Kleen
2006-10-04 14:07     ` Eric W. Biederman
2006-10-04 14:45       ` Vivek Goyal
2006-10-04 16:09   ` Andrew Morton
2006-10-04 16:14     ` Vivek Goyal
2006-10-03 17:10 ` [PATCH 4/12] i386: define __pa_symbol() Vivek Goyal
2006-10-04  8:26   ` Franck Bui-Huu
2006-10-04 19:44     ` Vivek Goyal
2006-10-06 13:10       ` Franck Bui-Huu
2006-10-06 18:33         ` Vivek Goyal
2006-10-03 17:12 ` [PATCH 5/12] i386 setup.c: Reserve kernel memory starting from _text Vivek Goyal
2006-10-03 17:15 ` [PATCH 6/12] i386: CONFIG_PHYSICAL_START cleanup Vivek Goyal
2006-10-03 18:45   ` Dave Hansen
2006-10-03 18:52     ` Vivek Goyal
2006-10-03 18:59     ` Eric W. Biederman
2006-10-03 19:35       ` Vivek Goyal
2006-10-03 17:17 ` [PATCH 7/12] Make linux/elf.h safe to be included in assembly files Vivek Goyal
2006-10-03 17:19 ` [PATCH 8/12] elf: Add ELFOSABI_STANDALONE to elf.h Vivek Goyal
2006-10-03 17:21 ` [PATCH 9/12] kallsyms: Generate relocatable symbols Vivek Goyal
2006-10-03 17:22 ` [PATCH 10/12] i386: Relocatable kernel support Vivek Goyal
2006-10-03 17:24 ` [PATCH 11/12] i386: Implement CONFIG_PHYSICAL_ALIGN Vivek Goyal
2006-10-03 17:25 ` [PATCH 12/12] i386 boot: Add an ELF header to bzImage Vivek Goyal
2006-10-04  3:13   ` Andrew Morton
2006-10-04  4:28     ` Vivek Goyal
2006-10-04  4:40       ` H. Peter Anvin
2006-10-04  8:04         ` Eric W. Biederman
2006-10-04 15:18           ` H. Peter Anvin
2006-10-05  4:12             ` Eric W. Biederman
2006-10-05  4:17               ` H. Peter Anvin
2006-10-04 20:22         ` Vivek Goyal
2006-10-04 20:27           ` H. Peter Anvin
2006-10-04 20:48             ` Vivek Goyal
2006-10-04 20:52               ` H. Peter Anvin
2006-10-04 21:06                 ` Vivek Goyal
2006-10-04 21:09                   ` H. Peter Anvin
2006-10-04  5:37       ` Andrew Morton
2006-10-05  4:06     ` Eric W. Biederman
2006-10-05  4:12       ` H. Peter Anvin
2006-10-05  4:44       ` Andrew Morton
2006-10-05  6:13         ` Eric W. Biederman
2006-10-05  6:31           ` Andrew Morton
2006-10-05  6:48             ` Eric W. Biederman
2006-10-05 21:54               ` Vivek Goyal
2006-10-05 15:25             ` H. Peter Anvin
2006-10-05 15:35               ` Eric W. Biederman
2006-10-05 15:29             ` Eric W. Biederman
2006-10-05 15:44               ` H. Peter Anvin
2006-10-06  6:59               ` Andrew Morton
2006-10-06 12:56                 ` Eric W. Biederman
2006-10-06 18:38                   ` Vivek Goyal
2006-10-06 18:54                     ` H. Peter Anvin
2006-10-06 19:09                       ` Eric W. Biederman
2006-10-06 21:54                         ` H. Peter Anvin
2006-10-09 14:33                           ` Vivek Goyal
2006-10-10  3:14                             ` Andrew Morton
2006-10-10  4:51                               ` Eric W. Biederman
2006-10-10 14:30                               ` Vivek Goyal
2006-10-10 18:46                                 ` Andrew Morton
2006-10-10 21:40                               ` Vivek Goyal
2006-10-11  2:35                                 ` Andrew Morton
2006-10-06 19:01                     ` Eric W. Biederman
2006-10-04  7:08   ` Eric W. Biederman
2006-10-04 14:23     ` Vivek Goyal
2006-10-05  3:09       ` Eric W. Biederman
2006-10-04 17:03     ` Vivek Goyal
2006-10-05  6:25       ` Eric W. Biederman
2006-10-05 21:34         ` Vivek Goyal

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=20061006233547.43888a48.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=ak@suse.de \
    --cc=dzickus@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=fastboot@lists.osdl.org \
    --cc=horms@verge.net.au \
    --cc=hpa@zytor.com \
    --cc=lace@jankratochvil.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lwang@redhat.com \
    --cc=magnus.damm@gmail.com \
    --cc=maneesh@in.ibm.com \
    --cc=vgoyal@in.ibm.com \
    /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