configure: Detect when glibc implements makecontext() to always fail

Improve the configure test for presence of ucontext functions by
making linker warnings fatal; this allows us to detect when we are
linked with a glibc which implements makecontext() to always return
ENOSYS.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
Compiling on an Ubuntu Natty ARM host will hit this.
(Anybody think we should clean up our configure tests so we can
enable -Werror and -Wl,--fatal-warnings on all of them?)

 configure |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

Am 12.10.2011 18:21, schrieb Peter Maydell:
> Improve the configure test for presence of ucontext functions by
> making linker warnings fatal; this allows us to detect when we are
> linked with a glibc which implements makecontext() to always return
> ENOSYS.
>
> Signed-off-by: Peter Maydell<peter.maydell@linaro.org>

Tested-by: Andreas Färber <afaerber@suse.de>

> ---
> Compiling on an Ubuntu Natty ARM host will hit this.

Works on Ubuntu Maverick ARM host as well.

> (Anybody think we should clean up our configure tests so we can
> enable -Werror and -Wl,--fatal-warnings on all of them?)

In theory that would be nice. I noticed for example that a missing 
glib2-devel package is not caught by configure, on openSUSE.

As a start for cleaning up...

>   configure |    7 +++++--
>   1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index 9b4fe34..4d9d9e0 100755
> --- a/configure
> +++ b/configure
> @@ -2549,9 +2549,12 @@ ucontext_coroutine=no
>   if test "$darwin" != "yes"; then
>     cat>  $TMPC<<  EOF
>   #include<ucontext.h>
> -int main(void) { makecontext(0, 0, 0); }
> +int main(void) { makecontext(0, 0, 0); return 0; }

...we could give a good example by adopting regular multi-line Coding 
Style, like accept4() and others.

Andreas

>   EOF
> -  if compile_prog "" "" ; then
> +  # Note that we enable fatal linker warnings to catch the
> +  # glibc "makecontext is not implemented and will always fail"
> +  # linker warning.
> +  if compile_prog "-Wl,--fatal-warnings" "" ; then
>         ucontext_coroutine=yes
>     fi
>   fi

Am 13.10.2011 16:26, schrieb Andreas Färber:
> Am 12.10.2011 18:21, schrieb Peter Maydell:
>> Improve the configure test for presence of ucontext functions by
>> making linker warnings fatal; this allows us to detect when we are
>> linked with a glibc which implements makecontext() to always return
>> ENOSYS.
>>
>> Signed-off-by: Peter Maydell<peter.maydell@linaro.org>
> 
> Tested-by: Andreas Färber <afaerber@suse.de>
> 
>> ---
>> Compiling on an Ubuntu Natty ARM host will hit this.
> 
> Works on Ubuntu Maverick ARM host as well.

Erm... This works great, also for accept4(), on Linux, but it's not
portable. Apple ld(1) doesn't seem to have --fatal-warnings.

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/Xcode-3.2.5/man1/ld.1.html

Sun/Oracle ld(1) does seem to have it as alias to -z fatal-warnings.

http://download.oracle.com/docs/cd/E19963-01/html/821-1461/ld-1.html

So, we'd have to check for valid linker options first?

Andreas

On 13 October 2011 23:23, Andreas Färber <andreas.faerber@web.de> wrote:
> Am 13.10.2011 16:26, schrieb Andreas Färber:
>> Am 12.10.2011 18:21, schrieb Peter Maydell:
>>> Improve the configure test for presence of ucontext functions by
>>> making linker warnings fatal; this allows us to detect when we are
>>> linked with a glibc which implements makecontext() to always return
>>> ENOSYS.
>>> ---
>>> Compiling on an Ubuntu Natty ARM host will hit this.
>>
>> Works on Ubuntu Maverick ARM host as well.
>
> Erm... This works great, also for accept4(), on Linux, but it's not
> portable. Apple ld(1) doesn't seem to have --fatal-warnings.

I've also just discovered that it's no use on Oneiric,
where the linker warning has gone away but the syscall
still always returns ENOSYS.

I think we should just always use the gthread implementation
rather than preferring a non-portable-and-hard-to-detect
set of functions (which increases the set of different
configs we need to test with). If there's a performance problem
with that we should get it fixed in gthread :-)

-- PMM

On 10/14/2011 02:30 PM, Peter Maydell wrote:
> I've also just discovered that it's no use on Oneiric,
> where the linker warning has gone away but the syscall
> still always returns ENOSYS.
>
> I think we should just always use the gthread implementation
> rather than preferring a non-portable-and-hard-to-detect
> set of functions (which increases the set of different
> configs we need to test with). If there's a performance problem
> with that we should get it fixed in gthread:-)

A user-space longjmp will always be slower than a mutex+condvar+context 
switch.  We're talking _orders of magnitude_ slower.  At this point it's 
better to write assembly, since we already support only a dozen TCG targets.

I played with an alternative implementation using a 2-barrier instead of 
mutex+condvar, but it didn't give any speedup and was still much slower 
than gthread.

Paolo

On 10/14/2011 02:47 PM, Paolo Bonzini wrote:
> A user-space longjmp will always be slower than a mutex+condvar+context
> switch.

Gah, I obviously meant faster. :)

Paolo

On 14 October 2011 13:55, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 10/14/2011 02:47 PM, Paolo Bonzini wrote:
>>
>> A user-space longjmp will always be slower than a mutex+condvar+context
>> switch.
>
> Gah, I obviously meant faster. :)

Ah, I hadn't actually looked at the coroutine-gthread.c code, and
had assumed it was implementing coroutines via a gthread coroutine
abstraction rather than via gthread real actual threads.

-- PMM