Re: [XenPPC] [PATCH] [POWERPC] fix vga.c compilation
On 16/8/06 1:30 am, Hollis Blanchard [EMAIL PROTECTED] wrote: Looks like I bungled this whitespace; could you fix when you commit please? It would probably be best to combine this patch with the ia64 patch and put both our signed-off lines on it. (I'll sign off on Alex's changes, FWIW.) I don't think the diffs between the arches should be sufficient to warrant whole new header files. I'll cook up a combined patch and post it,. -- Keir ___ 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 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
[XenPPC] stupid learning questions
spent a while on a wrong track, basically because a #endif didn't say wha tit was an endif for. (in xen/smp.h). I did a quick grep and half the endifs in .h files have a comment that says what #ifdef they correspond to, and the other half do not. Do we have a style for this?___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] commenting #endif
On Wed, 2006-08-16 at 10:09 -0400, Orran Y Krieger wrote:
spent a while on a wrong track, basically because a #endif didn't say
wha tit was an endif for. (in xen/smp.h). I did a quick grep and half
the endifs in .h files have a comment that says what #ifdef they
correspond to, and the other half do not. Do we have a style for
this?
I prefer commenting all the #endifs, and I have certainly tried to do
that in all PowerPC code. If you're asking about xen-wide style,
xen-devel would be a better place to ask (and perhaps submit a patch
that adds the missing comments).
I think most text editors support flipping between ifdef/endif just like
flipping between {}, which should make it pretty easy to figure out
which endif matches which ifdef. (In vi the command is % .)
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [Xen-devel] Re: [XenPPC] [PATCH] [POWERPC] fix vga.c compilation
On Wed, 2006-08-16 at 11:49 +0100, Keir Fraser wrote: Here you go. Arch/powerpc/vga.c isn't great but I assume it's temporary until vga support is fixed properly. If you think it looks okay I'll apply it. Also Sign-off or Ack if you like. Hi Keir, In general this looks a lot better, but I think ia64 is still going to have trouble with the chunk below. It seems that a VGA card operating in a standard text mode doesn't necessarily respond to all of these addresses. On some ia64 platforms that causes a hard fail response (the bus goes fatal and a reboot follows). On my system, the 0xB8000 test looks like it will probably work, but we never get there because either the 0xA or the 0xB test will cause the hardfail. Do we need to poke the card through I/O port space to get it into the right mode before probing it in MMIO space? I don't know enough about the VGA programming model to be able to do that. The card works once we start talking to it correctly, but this probe is a little too brute force. Thanks, Alex + +p = ioremap(0xA, 0x1000); +detected = detect_video(p); +iounmap(p); +if ( detected ) +return 1; + +p = ioremap(0xB, 0x1000); +detected = detect_video(p); +iounmap(p); +if ( detected ) +return 1; + +p = ioremap(0xB8000, 0x1000); +detected = detect_video(p); +iounmap(p); +if ( detected ) +return 1; + -- Alex Williamson HP Open Source Linux Org. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [Xen-devel] Re: [XenPPC] [PATCH] [POWERPC] fix vga.c compilation
On 16/8/06 2:59 pm, Alex Williamson [EMAIL PROTECTED] wrote: In general this looks a lot better, but I think ia64 is still going to have trouble with the chunk below. It seems that a VGA card operating in a standard text mode doesn't necessarily respond to all of these addresses. On some ia64 platforms that causes a hard fail response (the bus goes fatal and a reboot follows). On my system, the 0xB8000 test looks like it will probably work, but we never get there because either the 0xA or the 0xB test will cause the hardfail. Do we need to poke the card through I/O port space to get it into the right mode before probing it in MMIO space? I don't know enough about the VGA programming model to be able to do that. The card works once we start talking to it correctly, but this probe is a little too brute force. Thanks, Actually I'm not sure this is particularly necessary for headless x86 either. I could move the test to the end of setup_vga(), and only probe 0xb8000? x86 is more 'resilient' to random memory and port accesses. I don't think it'll matter that we do lots of port accesses even if a vga adapter isn't present. If we keep the conventional-ram test as well, then that'll be the same level of checking that Linux does on ia64. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Xencomm for xen/ia64
Hi, [xen-ppc-devel is on CC just for info] I am porting xen-ppc's xencomm to xen/ia64. Currently on xen/ia64 copy_from/to_guest uses guest virtual address. This works well as long as the virtual addresses are in the TLB. When not in TLB (or vTLB) the hypercall can't success without domain help. The possible solution is either to touch the memory areas before doing the hypercall and/or restarting the hypercall. Touching the memory area is an hack and we can't be sure it works. Restarting the hypercall is not always possible (some hypercalls are atomic: DOM0_SHADOW_CONTROL_OP_CLEAN) or can result in a live-lock. The most simple solution is to use guest physical addresses instead of virtual addresses. For hypercalls directly issued by the kernel, the translation is very easy. For hypercalls (indirectly) issued by dom0 though the ioctl, kernel has to do the translation. Because it may not be linear in guest physical memory the parameter is a pointer to a list of page (xencomm). The pros of such approach is simplicity and reliability. The main cons is maybe speed. Hopefully the most frequent hypercalls (dom0vp and eoi) either don't use in memory parameters (dom0vp) or may be modified so that they pass parameters through registers (eoi). IMHO speed won't be affected. Access to guest memory is also performed during vcpu_translate (to read vhpt) or EFI/PAL/SAL calls. We can either do not change that code (ie both mechanisms are not exclusive) or change the code. This point will be postpone. Comments are welcome (I won't work tomorrow, so you have more time). If we agree on using xencomm we will have to work with xen/ppc people in order not to duplicate the code. Hopefully it is rather small. I have enhanced the xencomm code so that the kernel may not use xencomm area but pass the guest physical address with a flag to know the space is linear in memory. At this time I can boot dom0 with xencomm. I will publish the patch later. Tristan. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] fix vga.c compilation
On Wed, 2006-08-16 at 11:49 +0100, Keir Fraser wrote:
@@ -159,12 +160,8 @@
* into a single 16-bit quantity */
#define VGA_OUT16VAL(v, r) (((v) 8) | (r))
-#if defined(__i386__) || defined(__x86_64__)
-# define vgabase 0
-# define VGA_OUTW_WRITE
-# define vga_readb(x) (*(x))
-# define vga_writeb(x,y) (*(y) = (x))
-#endif
+#define vgabase 0 /* use in/out port-access macros */
+#define VGA_OUTW_WRITE/* can use outw instead of 2xoutb */
When would you redefine vgabase?
diff -r ec03b24a2d83 xen/arch/powerpc/vga.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/xen/arch/powerpc/vga.cWed Aug 16 11:44:31 2006 +0100
@@ -0,0 +1,21 @@
+#include xen/types.h
+#include xen/font.h
+#include xen/vga.h
+
+/* Temporary dummy versions until the VGA driver is fixed. */
+
+void *setup_vga(void)
+{
+return NULL;
+}
+
+void vga_cursor_off(void)
+{
+}
+
+int vga_load_font(const struct font_desc *desc, unsigned rows)
+{
+return -1;
+}
+
+const struct font_desc font_vga_8x8, font_vga_8x14, font_vga_8x16;
I think there could be a cleaner separation between console.c and vga.c,
and that would avoid needing to redefine these symbols. For example,
right now cls(), init_vga(), and others still live in console.c, most of
them manually testing vgacon_enabled.
What would be better is a system where console drivers (i.e. serial and
vga) register themselves at boot time, so console.c putchar() becomes:
void __putstr(char *str)
{
struct console_driver *d;
for (d = console_list; d != NULL; d = d-next)
d-putstr(str);
}
Then all that serial-specific and vga-specific code can be removed from
console.c, and that would make disabling VGA at compile time much more
clean.
--
Hollis Blanchard
IBM Linux Technology Center
___
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] mini-os
Mini-os on x86 seems to work. Someone working with us has successfully augmented it with a stripped down version of the J9 JVM. I have another question related to small, non-linux, os'es that can be used as a model to build a domU for xen/ppc. I am basically redoing a similar thing, that is a small domU with a stipped down JVM. I was hoping to start with a working, small os . Are there any out there that have been ported to Xen/ppc? Hollis Blanchard wrote: On Tue, 2006-08-15 at 15:13 -0400, Maria Butrico wrote: What is the correct invocation for building mini-os for powerpc? I don't believe anybody has ever tried it. In fact I seem to recall hearing that for a while mini-os didn't even work for x86-64, so I have grave doubts as to its portability. I haven't even glanced at it myself. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] packages needed to support xen tools
From the xen/ppc wiki: --- For convenience, here is a list of rpms I needed for Dom0 running SLES-10 *libgcrypt-devel*, *glibc-devel*, *python-devel*, *ncurses-devel-5.5-18*, *zlib-devel*, *openssl-devel*, and *gcc*. I am looking at the sles10 install dvd images. We have libgcrypt-devel-1.2.2-13.2.ppc.rpm and libgcrypt-devel-64bit-1.2.2-13.2.ppc.rpm ./suse/ppc/glibc-devel-2.4-31.2.ppc.rpm ./suse/ppc/glibc-devel-64bit-2.4-31.2.ppc.rpm ./suse/ppc/ncurses-devel-5.5-18.2.ppc.rpm ./suse/ppc/ncurses-devel-64bit-5.5-18.2.ppc.rpm ./suse/ppc/zlib-devel-1.2.3-15.2.ppc.rpm ./suse/ppc/zlib-devel-64bit-1.2.3-15.2.ppc.rpm ./suse/ppc/openssl-devel-0.9.8a-18.4.ppc.rpm ./suse/ppc/openssl-devel-64bit-0.9.8a-18.4.ppc.rpm and a whole bunch of gcc. Which ones are the ones I want? (There is only one python-devel) ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [XEND] abstract architecture-specific bits in image.py
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Node ID 2d465991275d5ca7f1ae8a27ad35ca41ece5cd06
# Parent 41827ce2ccebf927df251ce3024eb10023de7d5b
[XEND] abstract architecture-specific bits in image.py
- create arch.type (which evaluates to x86, ia64 or powerpc)
- create subclasses for x86 and ia64 HVM loaders
- rework findImageHandlerClass()
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
---
tools/python/xen/xend/XendDomainInfo.py | 25 ++---
tools/python/xen/xend/arch.py | 31 +++
tools/python/xen/xend/image.py | 86
3 files changed, 83 insertions(+), 59 deletions(-)
diff -r 41827ce2cceb -r 2d465991275d tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py Mon Aug 14 19:22:16 2006 -0500
+++ b/tools/python/xen/xend/XendDomainInfo.py Wed Aug 16 17:19:38 2006 -0500
@@ -1279,23 +1279,14 @@ class XendDomainInfo:
cpu = [ int( cpus[v % len(cpus)] ) ]
xc.vcpu_setaffinity(self.domid, v, cpu)
-# set domain maxmem in KiB
-xc.domain_setmaxmem(self.domid, self.info['maxmem'] * 1024)
-
-m = self.image.getDomainMemory(self.info['memory'] * 1024)
-balloon.free(m)
-
-init_reservation = self.info['memory'] * 1024
-if os.uname()[4] in ('ia64', 'ppc64'):
-# Workaround for architectures that don't yet support
-# ballooning.
-init_reservation = m
-# Following line from [EMAIL PROTECTED]
-# Needed for IA64 until supports ballooning -- okay for PPC64?
-xc.domain_setmaxmem(self.domid, m)
-
-xc.domain_memory_increase_reservation(self.domid, init_reservation,
- 0, 0)
+# set memory limit
+maxmem = self.image.getRequiredMemory(self.info['maxmem'] * 1024)
+xc.domain_setmaxmem(self.domid, maxmem)
+
+# initial memory allocation
+mem_kb = self.image.getRequiredMemory(self.info['memory'] * 1024)
+balloon.free(mem_kb)
+xc.domain_memory_increase_reservation(self.domid, mem_kb, 0, 0)
self.createChannels()
diff -r 41827ce2cceb -r 2d465991275d tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.pyMon Aug 14 19:22:16 2006 -0500
+++ b/tools/python/xen/xend/image.pyWed Aug 16 17:19:38 2006 -0500
@@ -27,6 +27,7 @@ from xen.xend.XendLogging import log
from xen.xend.XendLogging import log
from xen.xend.server.netif import randomMAC
from xen.xend.xenstore.xswatch import xswatch
+from xen.xend import arch
xc = xen.lowlevel.xc.xc()
@@ -141,16 +142,7 @@ class ImageHandler:
raise VmError('Building domain failed: ostype=%s dom=%d err=%s'
% (self.ostype, self.vm.getDomid(), str(result)))
-
-def getDomainMemory(self, mem_kb):
-@return The memory required, in KiB, by the domain to store the
-given amount, also in KiB.
-if os.uname()[4] != 'ia64':
-# A little extra because auto-ballooning is broken w.r.t. HVM
-# guests. Also, slack is necessary for live migration since that
-# uses shadow page tables.
-if 'hvm' in xc.xeninfo()['xen_caps']:
-mem_kb += 4*1024;
+def getRequiredMemory(self, mem_kb):
return mem_kb
def buildDomain(self):
@@ -192,8 +184,6 @@ class LinuxImageHandler(ImageHandler):
features = self.vm.getFeatures())
class HVMImageHandler(ImageHandler):
-
-ostype = hvm
def configure(self, imageConfig, deviceConfig):
ImageHandler.configure(self, imageConfig, deviceConfig)
@@ -349,21 +339,6 @@ class HVMImageHandler(ImageHandler):
os.waitpid(self.pid, 0)
self.pid = 0
-def getDomainMemory(self, mem_kb):
-@see ImageHandler.getDomainMemory
-if os.uname()[4] == 'ia64':
-page_kb = 16
-# ROM size for guest firmware, ioreq page and xenstore page
-extra_pages = 1024 + 2
-else:
-page_kb = 4
-# This was derived emperically:
-# 2.4 MB overhead per 1024 MB RAM + 8 MB constant
-# + 4 to avoid low-memory condition
-extra_mb = (2.4/1024) * (mem_kb/1024.0) + 12;
-extra_pages = int( math.ceil( extra_mb*1024 / page_kb ))
-return mem_kb + extra_pages * page_kb
-
def register_shutdown_watch(self):
add xen store watch on control/shutdown
self.shutdownWatch = xswatch(self.vm.dompath + /control/shutdown, \
@@ -400,15 +375,42 @@ class HVMImageHandler(ImageHandler):
return 1 # Keep watching
-Table of image handler classes for virtual machine images. Indexed by
-image type.
-
-imageHandlerClasses = {}
-
-
-for h in LinuxImageHandler,
[XenPPC] FYI: domU loading update
I just pushed three patches to xen-ppc-unstable that enable domU loading via xend. In particular, things like initrd loading and boot arguments in the xm create config file work properly[1]. This will cause merge headaches down the road, because Keir wants xc_linux_build() and related python to be drastically refactored upstream, but I think initrd support is important enough to push to our tree for now. I guess what I'm saying is please let me know if you want to make changes around xc_linux_build(), because I'm going to need to sort them all out later. [1] I tried an old ramdisk I had laying around, but init didn't manage to output any messages, so a) the initrd itself could be loaded incorrectly, or b) we have some other bug that's preventing userspace in a domU from working. I guess a) is probably more likely, but I don't intend to look into it in the immediate future. -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Current tip broken with SystemSim
On Wed, Aug 16, 2006 at 11:30:48AM -0500, Hollis Blanchard wrote: Add to the wiki, please: http://wiki.xensource.com/xenwiki/XenPPC/Run/SystemSim Also please add a note about the required memory increase. Done x2 When I workout how to get a root image under systemsim I'll document that aswell. 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 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
