durango.c:203: Error: suffix or operands invalid for `push' durango.c:208: Error: suffix or operands invalid for `mov' durango.c:209: Error: suffix or operands invalid for `mov' durango.c:210: Error: suffix or operands invalid for `mov' durango.c:214: Error: suffix or operands invalid for `pop' There are also similar compile errors in lx_driver.c. and cimarron.c. This has been compiled on Linux AMD64. Geode is an AMD 32 bit processor, the code uses unsigned long for pointers (32 bit on Geode, but 64 bit on AMD64) but makes assignments to int or 32 bit registers. I assume it's a video driver (integrated graphics) that is not expected to work on anything but Geode. From my readings, AMD announced no further development on Geode, so it is unlikely there will be a 64-bit version. The proposed solution is to build the geode driver on i686 architecture CPUs only. The command 'uname -m' for Geode returns i686. I'll provide a patch for this solution but I'll be happy to implement a patch for another solution. Assembler details: ============================================================= gfx_msr_asm_write(unsigned short reg, unsigned long addr, unsigned long *hi, unsigned long *lo) #define vsa_msr_write(msr,adr,high,low) \ { int d0, d1, d2, d3, d4; \ __asm__ __volatile__( \ " push %%ebx\n" \ Works when changing ebx for rbx " mov $0x0AC1C, %%edx\n" \ " mov $0xFC530007, %%eax\n" \ " out %%eax,%%dx\n" \ " add $2,%%dl\n" \ " mov %6, %%ebx\n" \ Can't moved a long to a 32 bit reg " mov %7, %0\n" \ Can't assign input "low" to "d0" " mov %5, %3\n" \ Can't assign input (msr|adr) to "d3" " xor %2, %2\n" \ " xor %1, %1\n" \ " out %%ax, %%dx\n" \ " pop %%ebx\n" \ Works when changing ebx for rbx : "=a"(d0),"=&D"(d1),"=&S"(d2), \ "=c"(d3),"=d"(d4) \ : "1"(msr | adr),"2"(*(high)),"3"(*(low))); \ }
Created attachment 28065 [details] [PATCH] build.sh: build video-geode on i686 only #22979
> --- Comment #1 from Gaetan Nadon <memsize@videotron.ca> 2009-07-27 17:40:14 PST --- > Created an attachment (id=28065) > --> (http://bugs.freedesktop.org/attachment.cgi?id=28065) > [PATCH] build.sh: build video-geode on i686 only #22979 > the check should probably not be for i686 specifically. See the vmmouse or intel checks for example (also uname -m is a pretty bad way to check for the target architecture, you can build 32bit code on amd64 just fine...)
(In reply to comment #2) > > --- Comment #1 from Gaetan Nadon <memsize@videotron.ca> 2009-07-27 17:40:14 PST --- > > Created an attachment (id=28065) [details] > > --> (http://bugs.freedesktop.org/attachment.cgi?id=28065) > > [PATCH] build.sh: build video-geode on i686 only #22979 > > > the check should probably not be for i686 specifically. See the vmmouse Thanks Julien, I agree, i686 is not accurate enough, just did not know what else to pick. > or intel checks for example (also uname -m is a pretty bad way to check In build.sh: both use: case $HOST_CPU in i*86* | amd64* | x86*64*) and HOST_CPU is assigned the value of uname -m. Anywhere else I should be looking? > for the target architecture, you can build 32bit code on amd64 just > fine...) One can install a 32-bit Linux O/S on AMD64. In that case uname returns i686 as opposed to x86_64. > My goal was not to identify a 32-bit O/S on AMD, just to filter out LP64 systems to prevent build failure. It's ok if it builds on any non AMD i686 CPU even if it is not intended to run on such CPUs. Is there a 64-bit O/S running X Window where uname -m returns i686? Looking again on the net, I found a Geode LX reporting i586: root@alix:~$ uname -m i586 I'll replace this patch with one that checks for i*86* just to be safe. I'll be happy to consider other solutions (preventing build breaks while letting Geode compile is good enough) or even drop the whole thing if it is deemed too risky.
Created attachment 28208 [details] [review] [PATCH] build.sh: build video-geode on i*86* only #22979
patch forwarded to xorg-devel for comments.
Pushed as 1165bdd1e1dcd4697aaf67386a4056626dc4efdf. Thanks for the patch.
This is still present when doing a full source build using jhbuild - filed as bug 26341.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.