Bug 22979

Summary: geode: inline assembler fails on 64-bit platforms
Product: xorg Reporter: Gaetan Nadon <memsize>
Component: Build/ModularAssignee: Gaetan Nadon <memsize>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: dgerard, peter.hutterer
Version: gitKeywords: janitor
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
[PATCH] build.sh: build video-geode on i686 only #22979
none
[PATCH] build.sh: build video-geode on i*86* only #22979 none

Description Gaetan Nadon 2009-07-27 17:31:46 UTC
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))); \
  }
Comment 1 Gaetan Nadon 2009-07-27 17:40:14 UTC
Created attachment 28065 [details]
[PATCH] build.sh: build video-geode on i686 only #22979
Comment 2 Julien Cristau 2009-07-30 08:21:46 UTC
> --- 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...)
Comment 3 Gaetan Nadon 2009-07-30 18:38:57 UTC
(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.


Comment 4 Gaetan Nadon 2009-07-30 18:39:39 UTC
Created attachment 28208 [details] [review]
[PATCH] build.sh: build video-geode on i*86* only #22979
Comment 5 Peter Hutterer 2009-08-25 15:46:41 UTC
patch forwarded to xorg-devel for comments.
Comment 6 Peter Hutterer 2009-08-26 15:40:37 UTC
Pushed as 1165bdd1e1dcd4697aaf67386a4056626dc4efdf. Thanks for the patch.
Comment 7 David Gerard 2010-01-30 18:10:46 UTC
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.