diff options
author | Tejun Heo <tj@kernel.org> | 2009-01-30 16:32:22 +0900 |
---|---|---|
committer | Ingo Molnar <mingo@elte.hu> | 2009-01-30 23:27:46 +0100 |
commit | 3ac6cffea4aa18007a454a7442da2855882f403d (patch) | |
tree | 4e784abaa1715728cb8fd2adbce793e30304d3b7 /net/9p | |
parent | c43e0e46adf79c321ed3fbf0351e1005fb8a2413 (diff) | |
download | op-kernel-dev-3ac6cffea4aa18007a454a7442da2855882f403d.zip op-kernel-dev-3ac6cffea4aa18007a454a7442da2855882f403d.tar.gz |
linker script: use separate simpler definition for PERCPU()
Impact: fix linker screwup on x86_32
Recent x86_64 zerobased patches introduced PERCPU_VADDR() to put
.data.percpu to a predefined address and re-defined PERCPU() in terms
of it. The new macro defined one extra symbol, __per_cpu_load, for
LMA of the section so that the init data could be accessed. This new
symbol introduced the following problems to x86_32.
1. If __per_cpu_load is defined outside of .data.percpu as an absolute
symbol, relocation generation for relocatable kernel fails due to
absolute relocation.
2. If __per_cpu_load is put inside .data.percpu with absolute address
assignment to work around #1, linker gets confused and under
certain configurations ends up relocating the symbol against
.data.percpu such that the load address gets added on top of
already set load address.
As x86_32 doesn't use predefined address for .data.percpu, there's no
need for it to care about the possibility of __per_cpu_load being
different from __per_cpu_start.
This patch defines PERCPU() separately so that __per_cpu_load is
defined inside .data.percpu so that everything is ordinary
linking-wise.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'net/9p')
0 files changed, 0 insertions, 0 deletions