[Bug target/16331] x86-64 inline asm register constraints insufficient WRT ABI

["thutt at vmware dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #13 from thutt at vmware dot com  2009-02-10 14:34 -------
(In reply to comment #12)
> (In reply to comment #11)
> > Uros, how hard to support this in x86 backend?
>

<snip>

> OTOH, constraints should be used to support correct register
> allocation for machine instructions, not to emulate ABI in order to
> support calls from inside asm statements.

Please indulge me for a moment.

What exactly is a call?

Are you considering the only method of transferring control to be the
standard 'near call' & 'near ret' instructions on the x86?

What about the following modes of transferring control to another
address?

   int
   iret
   ret
   sysenter
   sysexit
   syscall
   sysret
   ud2
   int3
   jmp

Then, what of these?

   lcall
   lret
   ljmp

Every one of these is a method to transfer control to another address
with a programmer-defined set of input register.  More importantly,
none of these are directly supported by gcc to invoke functions
without resorting to inline assembly.

If you're working on an operating system, a virtualization engine or
some other embedded device you might need to transfer control using
one of these methods.

As a really simple example, consider a handler for a timer interrupt.
Let's say that the prologue for the interrupt (written in assembly)
handler storing all the machine registers into a data structure
accessible from C.  Then, the prologue transfers to the handler which is
conveniently written in C.  Wouldn't it be really nice if one could
restore all the saved registers in C code using only inline assembly
instruction?

    __asm__("iret"
            :
            : force restoring registers saved in data structure);

I'm confident you can see the advantage of doing this in C and letting
the compiler deal with the bookkeeping details, rather than resorting
to another assembly language function which does such a simple feat.

I think I pretty clearly demonstrate here that calling other functions
using the x86 architecture isn't as simple as assuming it's going only
to be done with 'call', 'jmp' and 'ret', and many of those methods are
not possible with straight C, even with gcc's helpful extensions.

Should gcc prevent the developer from using the ABI just because the
inline assembly wasn't meant to 'support calls from inside assembly
statements'?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331