Re: [XenPPC] PHDR link failure testcase
On Aug 15, 2006, at 2:41 AM, Tony Breeds wrote: On Mon, Aug 14, 2006 at 07:17:37PM -0400, Amos Waterland wrote: Using a `powerpc64-linux-gcc (GCC) 4.1.1 ()' x86-ppc toolchain, if I do this: diff -r 9563f5c9ab19 xen/include/asm-powerpc/config.h snip /usr/powerpc64/lib/gcc/powerpc64-linux/4.1.1/../../../../powerpc64- linux/bin/ld: /home/apw/devel/xen/xen.hg/xen/xen-syms: Not enough room for program headers (allocated 2, need 3) I believe the root cause for this is the fact that the .data.percpu section is becoming large. Thanks for getting to the bottom of this Tony. As it's empty the linker decides to start a 3rd segment rather than waste disk space. Hmm, what is empty? Initially the linker guessed it would need 2 segments, but due to this decision it actually uses 3, causeing the abort. Aparently the newer (read current CVS) tools don't abort here but do the right thing. What _is_ the right thing? I have 2 solutions to this problem. 1) Explicitly add 3 segmnets in the linker script and manually map sections to segments. 2) Use the linker script to manually place a bogus data element in the .data.percpu section, which results in the linker doign the right thing. I'm not in a position to judge which is better over the longer term but option 2 is a gross hack. Perhaps, this is just mythology/warm-n-fuzzy for me, but I really like having 1 PHDR. Lemmy collect my thoughts and come up with a rational reason. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] PHDR link failure testcase
Perhaps, this is just mythology/warm-n-fuzzy for me, but I really like having 1 PHDR. Lemmy collect my thoughts and come up with a rational reason. 1 PHDR works just as well; the important thing is to explicitly define your PHDRs in the linker script. Segher ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] PHDR link failure testcase
On Wed, Aug 16, 2006 at 08:10:20AM -0400, Jimi Xenidis wrote:
Thanks for getting to the bottom of this Tony.
As it's empty the linker decides to start a
3rd segment rather than waste disk space.
Hmm, what is empty?
By empty I mean filled with 0s, which I believe is because all the
per_cpu variables are initialised at runtime.
Initially the linker guessed
it would need 2 segments, but due to this decision it actually uses 3,
causeing the abort.
Aparently the newer (read current CVS) tools don't abort here but do
the right thing.
What _is_ the right thing?
Use 3 PHDRS.
Perhaps, this is just mythology/warm-n-fuzzy for me, but I really
like having 1 PHDR.
Lemmy collect my thoughts and come up with a rational reason.
Sure. Wouldn't that mean that everything will end up being in a
read/write/execute PHDR. Do we care about that?
Placing everything in one PHDR would look like:
---
diff -r 279843441136 xen/arch/powerpc/xen.lds.S
--- a/xen/arch/powerpc/xen.lds.SWed Aug 16 17:19:38 2006 -0500
+++ b/xen/arch/powerpc/xen.lds.SThu Aug 17 11:30:50 2006 +1000
@@ -10,11 +10,15 @@ SEARCH_DIR(=/usr/local/lib64); SEARCH_
SEARCH_DIR(=/usr/local/lib64); SEARCH_DIR(=/lib64);
SEARCH_DIR(=/usr/lib64); SEARCH_DIR(=/usr/local/lib); SEARCH_DIR(=/lib);
SEARCH_DIR(=/usr/lib);
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
+PHDRS
+{
+ text PT_LOAD FILEHDR PHDRS;
+}
SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = 0x1000); . = 0x1000 + SIZEOF_HEADERS;
- .interp : { *(.interp) }
+ .interp : { *(.interp) } :text
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
@@ -121,7 +125,7 @@ SECTIONS
__inithcall_end = .;
__per_cpu_start = .;
- .data.percpu : { *(.data.percpu) } :text
+ .data.percpu : { *(.data.percpu) }
__per_cpu_data_end = .;
. = __per_cpu_start + (NR_CPUS PERCPU_SHIFT);
. = ALIGN(STACK_SIZE);
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2007.linux.org.au/
Jan 15-20 2007 The Australian Linux Technical Conference!
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] PHDR link failure testcase
On Aug 16, 2006, at 10:00 PM, Tony Breeds wrote:
On Wed, Aug 16, 2006 at 08:10:20AM -0400, Jimi Xenidis wrote:
Thanks for getting to the bottom of this Tony.
As it's empty the linker decides to start a
3rd segment rather than waste disk space.
Hmm, what is empty?
By empty I mean filled with 0s, which I believe is because all the
per_cpu variables are initialised at runtime.
so why does LONG(0) (from option (2)) fix this?
Initially the linker guessed
it would need 2 segments, but due to this decision it actually
uses 3,
causeing the abort.
Aparently the newer (read current CVS) tools don't abort here but do
the right thing.
What _is_ the right thing?
Use 3 PHDRS.
Ok.
Perhaps, this is just mythology/warm-n-fuzzy for me, but I really
like having 1 PHDR.
Lemmy collect my thoughts and come up with a rational reason.
Sure. Wouldn't that mean that everything will end up being in a
read/write/execute PHDR. Do we care about that?
Not really its not like we protect any of it :) and the section
separation still exits
after-all we all (kernels/xen) link with -N/--omagic, which does not
page align the data sections which has always implied a single PHDR.
Besides, the more I do this the less I trust FW and bootloaders so a
single segment is just cleaner.
Placing everything in one PHDR would look like:
---
diff -r 279843441136 xen/arch/powerpc/xen.lds.S
--- a/xen/arch/powerpc/xen.lds.SWed Aug 16 17:19:38 2006 -0500
+++ b/xen/arch/powerpc/xen.lds.SThu Aug 17 11:30:50 2006 +1000
@@ -10,11 +10,15 @@ SEARCH_DIR(=/usr/local/lib64); SEARCH_
SEARCH_DIR(=/usr/local/lib64); SEARCH_DIR(=/lib64); SEARCH_DIR
(=/usr/lib64); SEARCH_DIR(=/usr/local/lib); SEARCH_DIR(=/
lib); SEARCH_DIR(=/usr/lib);
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
+PHDRS
+{
+ text PT_LOAD FILEHDR PHDRS;
+}
I think this is all we need, not other changes are required.
SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = 0x1000); . = 0x1000 +
SIZEOF_HEADERS;
Actually the above line should just be:
PROVIDE (__executable_start = .);
We always specific the link address on the command line and not that
we define PHDRS there is no need for SIZEOF_HEADERS (as the linker
docs indicate)
I'm pretty sure the rest of the changes are unnecessary.
-JX
- .interp : { *(.interp) }
+ .interp : { *(.interp) } :text
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
@@ -121,7 +125,7 @@ SECTIONS
__inithcall_end = .;
__per_cpu_start = .;
- .data.percpu : { *(.data.percpu) } :text
+ .data.percpu : { *(.data.percpu) }
__per_cpu_data_end = .;
. = __per_cpu_start + (NR_CPUS PERCPU_SHIFT);
. = ALIGN(STACK_SIZE);
Yours Tony
linux.conf.au http://linux.conf.au/ || http://
lca2007.linux.org.au/
Jan 15-20 2007 The Australian Linux Technical Conference!
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
