[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] x86_64/entry.S:317: Error: `1(%eax)' is not a valid64 bit base/index


  • To: "Puthiyaparambil, Aravindh" <aravindh.puthiyaparambil@xxxxxxxxxx>
  • From: Jerone Young <jerone@xxxxxxxxx>
  • Date: Wed, 18 May 2005 21:28:54 -0500
  • Cc: David F Barrera <dfbp@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxx>
  • Delivery-date: Thu, 19 May 2005 02:28:23 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gWkIy67g0gXAHjgjbwarVkDehivB2hW4ZaN3/Zac2mIzogaYOPcpRgO+Uln7ZtXV1aFKv+lcRWQK71Dy75wX6+xynsZJm/n64F9V1HFncgmDRNMOLrouP5RauGwvbNSPAaZuES3vYOYxprMi/Hsg1Dt78zzOQceV3aAc8zNN36s=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

I looked into this problem breifely yesterday. This looks to be
something with SuSEs gcc setup. Right now this is the least of our
worries in x86-64 land (not that I'm not going to look  hard into it
and solve it). There are a lot of other problems with x86-64 Xen
eating up my time right now.  I worked on SLES9 bring up when it was
coming to release. I can tell you they put a lot of crazy patches in
their gcc that cause stuff like this. It's a matter of figuring out
what is triggering it. Because x86-64 Xen builds fine on Debian,
Ubuntoo, Gentoo, & Fedora.

On 5/18/05, Puthiyaparambil, Aravindh
<aravindh.puthiyaparambil@xxxxxxxxxx> wrote:
> So has the "prefetchw" bug been fixed?
> http://bugzilla.xensource.com/cgi-bin/bugzilla/show_bug.cgi?id=34.
> 
> I am still seeing it on SLES9 SP1 x86_64. I am using the latest unstable
> pull.
> 
> Aravindh
> 
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jerone Young
> Sent: Wednesday, May 18, 2005 3:57 PM
> To: Vincent Hanquez
> Cc: David F Barrera; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] x86_64/entry.S:317: Error: `1(%eax)' is not a
> valid64 bit base/index
> 
> The fix for this is in bitkeeper now. It did not make it into the
> unstable tar ball for the night. So you will not see this problem
> tommorow.
> 
> On 5/18/05, Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxx> wrote:
> > On Wed, May 18, 2005 at 10:59:00AM -0500, David F Barrera wrote:
> > > Using the May 17 xen-unstable-src.tgz on x86_64, the following error
> > > occurs on a SLES 9 SP1 platform (It builds OK on Fedora Core 4, but
> it
> > > does not boot, and that is another issue):
> > >
> > > gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing
> -iwithprefix include
> > > -Wall -Werror -Wno-pointer-arith -pipe
> -I/tmp/xen-unstable/xen/include
> > > -I/tmp/xen-unstable/xen/include/asm-x86/mach-default -O3
> -fomit-frame-pointer
> > > -msoft-float -m64 -mno-red-zone -fpic -fno-reorder-blocks
> > > -fno-asynchronous-unwind-tables -DNDEBUG -D__ASSEMBLY__ -c
> x86_64/entry.S -o
> > > x86_64/entry.o
> > > x86_64/entry.S: Assembler messages:
> > > x86_64/entry.S:317: Error: `1(%eax)' is not a valid 64 bit
> base/index
> > > expressionx86_64/entry.S:320: Error: `136+8(%esp)' is not a valid 64
> bit
> > > base/index expression
> >
> > that's odd. could you verify you have the correct line on entry.S ?
> >
> > line 317: setnz VCPUINFO_upcall_mask(%rax)
> > line 320: movw  UREGS_cs+8(%rsp),%ax
> >
> > as well, what compiler version are you using ?
> >
> > --
> > Vincent Hanquez
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> >
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.