Xen devel - Jul 2008 - porting xen-detect ASM code into a shared library

Hello list.

I''m trying to port xen-detect.c ASM code into cfengine, which is 
currently build as a shared library. However, I''m facing a compilation 
error:
misc.c: In function ''Xen_cpuid'':
misc.c:1376: error: can''t find a register in class
''BREG'' while
reloading ''asm''
misc.c:1376: error: ''asm'' operand has impossible constraints

 From 
http://sam.zoy.org/blog/2007-04-13-shlib-with-non-pic-code-have-inline-assembly-and-pic-mix-well,
it appears to be caused by the mix of -fPIC flag (mandatory for shared 
libraries in linux distributions), and the use of ebx register. Given 
than I''m quite clueless about ASM, I can''t figure out how to
solve this
issue.

Also, I slightly modified xen-detect.c code to better integration with 
cfengine code (dropped pv_context flags, as pv host are already detected 
by presence of /proc/xen entry, and turned method signature to 
non-static). Just tell me if I did something wrong.

Lastly, is this ASM code supposed to be portable among various Unix and 
architectures ?

Original file + patch included. Any help welcome.
-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62



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

On 10/7/08 10:21, "Guillaume Rousse" <Guillaume.Rousse@inria.fr>
wrote:
> I''m trying to port xen-detect.c ASM code into cfengine, which is
> currently build as a shared library. However, I''m facing a
compilation
> error:
> misc.c: In function ''Xen_cpuid'':
> misc.c:1376: error: can''t find a register in class
''BREG'' while
> reloading ''asm''
> misc.c:1376: error: ''asm'' operand has impossible
constraints
> 
>  From 
See tools/libxc/xc_cpuid_x86.c for an example of how to work around this.
Essentially you turn the "=b" constraint into "=r". You then
push/pop ebx
(to save/restore it) and you ''mov %%ebx,%1'' to save away
ebx''s value before
restoring its original value.

 -- Keir



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

Keir Fraser a écrit :
> 
> 
> On 10/7/08 10:21, "Guillaume Rousse"
<Guillaume.Rousse@inria.fr> wrote:
> 
>> I''m trying to port xen-detect.c ASM code into cfengine, which
is
>> currently build as a shared library. However, I''m facing a
compilation
>> error:
>> misc.c: In function ''Xen_cpuid'':
>> misc.c:1376: error: can''t find a register in class
''BREG'' while
>> reloading ''asm''
>> misc.c:1376: error: ''asm'' operand has impossible
constraints
>>
>>  From 
> 
> See tools/libxc/xc_cpuid_x86.c for an example of how to work around this.
> Essentially you turn the "=b" constraint into "=r". You
then push/pop ebx
> (to save/restore it) and you ''mov %%ebx,%1'' to save away
ebx''s value before
> restoring its original value.
Thanks, I see the idea, but I feel like a typing monkey here because of 
the unknown syntax. Is this supposed to be OK ?

void Xen_cpuid(uint32_t idx, uint32_t *eax, uint32_t *ebx, uint32_t *ecx,
                   uint32_t *edx)
{
     asm volatile (
         "test %1,%1 ; jz 1f ; ud2a ; .ascii \"xen\" ;"

#ifdef __i386__
          "push %%ebx; cpuid; mov %%ebx,%1; pop %%ebx"
#else
          "push %%rbx; cpuid; mov %%ebx,%1; pop %%rbx"
#endif

         : "=a" (*eax), "=r" (*ebx), "=c" (*ecx),
"=d" (*edx)
         : "0" (idx), "1" (0) );
}

Also, the final line was originally:
: "0" (idx), "1" (pv_context) );

I turned it into the current way because I don''t need the check in pv 
context, but I guess it might be simplified.
-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62

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

On 10/7/08 11:54, "Guillaume Rousse" <Guillaume.Rousse@inria.fr>
wrote:
> I turned it into the current way because I don''t need the check in
pv
> context, but I guess it might be simplified.
Actually then you can take the xc_cpuid_x86 function pretty much unmodified
(of course regs[0-3] become eax-edx, and input[1] is not needed).

The other stuff in the asm code is to ensure that cpuid traps into the
hypervisor when run in a pv guest. If you don''t need to run in a pv
guest
then you don''t need that extra code.

 -- Keir



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

Keir Fraser a écrit :
> On 10/7/08 11:54, "Guillaume Rousse"
<Guillaume.Rousse@inria.fr> wrote:
> 
>> I turned it into the current way because I don''t need the
check in pv
>> context, but I guess it might be simplified.
> 
> Actually then you can take the xc_cpuid_x86 function pretty much unmodified
> (of course regs[0-3] become eax-edx, and input[1] is not needed).
> 
> The other stuff in the asm code is to ensure that cpuid traps into the
> hypervisor when run in a pv guest. If you don''t need to run in a
pv guest
> then you don''t need that extra code.
OK, I tried this:

void Xen_cpuid(uint32_t idx, uint32_t *eax, uint32_t *ebx, uint32_t 
*ecx, uint32_t *edx)

{
      asm (
         /* %ebx register need to be saved before usage and restored 
thereafter
          * for PIC-compliant code on i386 */
#ifdef __i386__
         "push %%ebx; cpuid; mov %%ebx,%1; pop %%ebx"
#else
         "push %%rbx; cpuid; mov %%ebx,%1; pop %%rbx"
#endif
         : "=a" (*eax), "=r" (*ebx), "=c" (*ecx),
"=d" (*edx)
         : "" (idx), "2" (0) );

But it doesn''t build:
misc.c: In function ''Xen_cpuid'':
misc.c:1377: warning: asm operand 4 probably doesn''t match constraints
misc.c:1377: error: impossible constraint in ''asm''

According to what I understood from GCC-Inline-Assembly-HOWTO, the 4th 
operand is probably "=d" (*edx), but I don''t see the exact
issue.
-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62

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

On 10/7/08 12:42, "Guillaume Rousse" <Guillaume.Rousse@inria.fr>
wrote:
>          : "" (idx), "2" (0) );
Should be
  : "0" (idx));

 -- Keir



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

Keir Fraser a écrit :
> On 10/7/08 12:42, "Guillaume Rousse"
<Guillaume.Rousse@inria.fr> wrote:
> 
>>          : "" (idx), "2" (0) );
> 
> Should be
>   : "0" (idx));
Many thanks, it worked. I just hope this is not an error in original 
xc_cpuid_x86.c ccode (borrowed from 
http://lxr.xensource.com/lxr/source/tools/libxc/xc_cpuid_x86.c)

Can I ensure upstream cfengine maintainer about portability of this code 
among various platforms and systems ?
-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62

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

On 10/7/08 13:30, "Guillaume Rousse" <Guillaume.Rousse@inria.fr>
wrote:
> Many thanks, it worked. I just hope this is not an error in original
> xc_cpuid_x86.c ccode (borrowed from
> http://lxr.xensource.com/lxr/source/tools/libxc/xc_cpuid_x86.c)
> 
> Can I ensure upstream cfengine maintainer about portability of this code
> among various platforms and systems ?
It''s gcc and x86 specific of course. Beyond that it is portable (across
OSes
for example).

 -- Keir
 



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

Keir Fraser a écrit :
> 
> 
> On 10/7/08 13:30, "Guillaume Rousse"
<Guillaume.Rousse@inria.fr> wrote:
> 
>> Many thanks, it worked. I just hope this is not an error in original
>> xc_cpuid_x86.c ccode (borrowed from
>> http://lxr.xensource.com/lxr/source/tools/libxc/xc_cpuid_x86.c)
>>
>> Can I ensure upstream cfengine maintainer about portability of this
code
>> among various platforms and systems ?
> 
> It''s gcc and x86 specific of course. Beyond that it is portable
(across OSes
> for example).
What''s the point of #ifdef __i386__ for the %ebx register usage issue, 
if whose cpuid function is x86-only ? Or is it actually a way to 
distinguish between gcc and other compilers ?

And are they alternative for non-i386 arches ?
-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62

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

On 10/7/08 13:43, "Guillaume Rousse" <Guillaume.Rousse@inria.fr>
wrote:
>> It''s gcc and x86 specific of course. Beyond that it is
portable (across OSes
>> for example).
> What''s the point of #ifdef __i386__ for the %ebx register usage
issue,
> if whose cpuid function is x86-only ? Or is it actually a way to
> distinguish between gcc and other compilers ?
> 
> And are they alternative for non-i386 arches ?
__i386__ versus __x86_64__

 -- Keir



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