This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] Fix incorrectly named __kernel_get_tbfreq VDSO function
- From: "Ryan S. Arnold" <ryan dot arnold at gmail dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: libc-alpha <libc-alpha at sourceware dot org>, Anton Blanchard <anton at samba dot org>
- Date: Fri, 7 Dec 2012 14:42:21 -0600
- Subject: Re: [PATCH 1/2] Fix incorrectly named __kernel_get_tbfreq VDSO function
- References: <20120709112735.22c2e72b@kryten><CAAKybw8XrcTffP6TRXq0qg+5mpmp6NMHQnKpVf_nPPfhibLG9Q@mail.gmail.com><20121129.193503.1047178464074352872.davem@davemloft.net><CAAKybw-kpKmgtOJrxU9QENwea=QU+ZEFzgJviC7TcFEd2dyXMQ@mail.gmail.com><CAAKybw-xQZvaNm7dtQ6zMzK3omZM8C3P+iK6e6f8qzPWb6fvSg@mail.gmail.com>
On Fri, Nov 30, 2012 at 5:14 PM, Ryan S. Arnold <ryan.arnold@gmail.com> wrote:
>> There's something goofy happening during testing, so I'm going to see
>> if I can get to the bottom of it by tomorrow.
Tulio discovered that this is failing in powerpc32 because the
VSYSCALL macro casts the return type to (int) whereas the
timebase_freq is 64-bits. This doesn't fail in powerpc64 because I
removed the (int) cast from those macros last year. None-the-less,
returning from long long int from the macros is not a solution to this
problem.
I have a hand written asm fix for this specific vdso call. We're
investigating whether this can be provided via a simpler common C
routine. We don't want to use a mixture of C, CPP/Macro, and inline
asm as is currently in place because the existing syscall macros make
assumptions about compiler behavior that may not be true in the future
(like the compiler honoring 'register' requests).
I'll post the asm patch here soon but we may go with a C approach instead.
Ryan