Re: [XenPPC] PHDR link failure testcase

[Tony Breeds <tony@xxxxxxxxxxxxxxxxxx>]

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.  As it's empty the linker decides to start a
3rd segment rather than waste disk space.  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.

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.

Option 1; Looks like:
------
diff -r 9563f5c9ab19 xen/arch/powerpc/xen.lds.S
--- a/xen/arch/powerpc/xen.lds.S        Mon Aug 14 15:22:22 2006 -0500
+++ b/xen/arch/powerpc/xen.lds.S        Tue Aug 15 16:28:59 2006 +1000
@@ -10,11 +10,17 @@ 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;
+  data  PT_LOAD;
+  extra PT_LOAD;
+}
 SECTIONS
 {
   /* Read-only sections, merged into text segment: */
   PROVIDE (__executable_start = 0x10000000); . = 0x10000000 + SIZEOF_HEADERS;
-  .interp         : { *(.interp) }
+  .interp         : { *(.interp) } :text
   .hash           : { *(.hash) }
   .dynsym         : { *(.dynsym) }
   .dynstr         : { *(.dynstr) }
@@ -105,13 +111,13 @@ SECTIONS
   {
     *(.data .data.* .gnu.linkonce.d.*)
     SORT(CONSTRUCTORS)
-  }
+  } :data
 
   /* Xen addition */
 
   . = ALIGN(32);
   __setup_start = .;
-  .setup.init : { *(.setup.init) }
+  .setup.init : { *(.setup.init) } :text
   __setup_end = .;
   __initcall_start = .;
   .initcall.init : { *(.initcall.init) }
@@ -121,7 +127,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);
@@ -129,7 +135,7 @@ SECTIONS
 
   /* end Xen addition */
 
-  .data1          : { *(.data1) }
+  .data1          : { *(.data1) } :extra
   .tdata         : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
   .tbss                  : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
   .eh_frame       : { KEEP (*(.eh_frame)) }
------

Option 2; Looks like:
------
diff -r 9563f5c9ab19 xen/arch/powerpc/xen.lds.S
--- a/xen/arch/powerpc/xen.lds.S        Mon Aug 14 15:22:22 2006 -0500
+++ b/xen/arch/powerpc/xen.lds.S        Tue Aug 15 16:34:27 2006 +1000
@@ -121,11 +121,12 @@ 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);
+  . = __per_cpu_start + (NR_CPUS << PERCPU_SHIFT) - 4;
+  LONG(0);
   . = ALIGN(STACK_SIZE);
-  __per_cpu_end = .;
+  __per_cpu_end = .; }
 
   /* end Xen addition */
 
------

Both have been compiled and boot on the JS20 here.  Neither of these 2 patches
is suggested for inclusion ATM.  I wanted some feedback on which seems
better.

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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel