[lkml]   [2014]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] x86: Mark __vdso entries as asmlinkage
On Wed, Feb 26, 2014 at 9:22 PM, H. Peter Anvin <> wrote:
> On 02/26/2014 09:19 PM, Andy Lutomirski wrote:
>>> The normal ABI almost certainly makes more sense; as such -mregparm=3 is
>>> probably not what we want, and I suspect it makes more sense to just
>>> drop that from the CFLAGS line?
>> Hmm. What happens on a native 32-bit build? IIRC the whole kernel is
>> build with regparm(3).
> Well, the vdso is still built separately, so we can use different CFLAGS
> if we want to.
>> If we want to save a cycle or two, then regparm(3) is probably faster.
>> But I think that these functions should either be asmlinkage or (on
>> 32 bit builds) explicitly regparm(3) to avoid confusion.
> I suggest using the standard ABI, but I suggest doing it via CFLAGS.

Hmm. This sort of goes against existing x86_32 practice where,
AFAICT, things that need a particular calling convention specify
asmlinkage and everything else uses regparm(3) if config/kbuild thinks
it's appropriate.

But I'm happy to resubmit the patch if you prefer the CFLAGS approach
for the 32-bit vdso. I don't think anything will break, since I don't
think that the 32-bit vdso has any other exported C code.

> It isn't any faster if the C library has to provide a wrapper just to
> marshal parameters.

Probably true, given that the glibc wrapper could, in principle, use
an optimized tail call. Also, I see no reason why vdso functions,
alone of all userspace code, should be special.


 \ /
  Last update: 2014-02-27 21:41    [W:0.095 / U:3.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site