[cfe-dev] variable length argument functions in AMD64 arch

[Zhi Wang]

Thanks, Eli. It was my fault that the stack wasn't 16-byte aligned. Since I
was compiling
a OS kernel with clang, I had to set rsp myself. I made a mistake in one of
the assembly
code. Now, it has been fixed and everything is fine.


BTW, it seems clang can't handle the "=rm" inline assembly code as in the
following:
static inline struct pcpu_gs *percpu ()
{
        struct pcpu_gs         *gs;

        asm volatile ("movq %%gs:gs_self, %0" : "=rm" (gs));
        return gs;
}

clang will generate code like:

movq %gs:gs_self, -8(%rbp)

leading gas to complain: Error: too many memory references for `movq'


--Zhi

On Thu, Aug 13, 2009 at 5:39 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Thu, Aug 13, 2009 at 1:26 PM, Zhi Wang<beiyuw at gmail.com> wrote:
> > It seems clang will generate code to handle variable length arguments
> > no matter whether
> > va_xxx (va_start, va_end) is used or not. (gcc will only generate code
> > to handle varible
> > length arguments when va_start is used).
>
> I suppose that's a quality-of-implementation issue; it's really more
> of a backend issue, though, so I'd suggest asking on llvmdev.
>
> > My biggest issue with this code is that movaps is used. According to
> > Intel's manual,
> > if the destination memory isn't 16-byte aligned, a GP# (General
> > Protection fault) will occur.
> > It seems that using movaps is wrong unless we can guarantee that ebp
> > is always 16byte aligned.
> > This may not be true. I manually edited the binary of generated code
> > to use the movups
> > (the same instruction as movups except that it will not check the
> > alignment). instruction
> > and everything is fine.
>
> The stack is supposed to be 16-byte aligned on x86-64; if it isn't,
> there's probably a bug somewhere.  But again, better to discuss on
> llvmdev.
>
> -Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090817/50a143b1/attachment.html>