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