Re: userspace-rcu-0.8.6 problems on MacOSX

Re: userspace-rcu-0.8.6 problems on MacOSX

[Alexandre Montplaisir]

Hi,

Technically, liburcu is not supported on Mac, but if we can easily make 
it work, why not try!

I tried compiling it on an OS X system (Yosemite, autoconf/automake 
installed from Homebrew), but got many errors like this one:

In file included from wfcqueue.c:26:

./urcu/static/wfcqueue.h:260:22: error: passing 'struct __cds_wfcq_head *' to parameter of incompatible type 'cds_wfcq_head_ptr_t'

         if (_cds_wfcq_empty(head, tail))

                             ^~~~

./urcu/static/wfcqueue.h:132:56: note: passing argument to parameter 'u_head' here

static inline bool _cds_wfcq_empty(cds_wfcq_head_ptr_t u_head,

                                                        ^

What steps did you use to make it compile?

Cheers,
Alexandre


On 2015-03-11 11:50 AM, Jim Reid wrote:
> Hi. There are some problems getting this to compile on MacOSX (10.9.5):
>
> 1) Many of the make regtest tests fail because the time command use command line arguments. eg:
>
> ...
> ./test_urcu_lgc 4 4 10 -d 2 -b 32768
> /usr/bin/time: illegal option -- a
> usage: time [-lp] command.
> ...
>
> 2) The generated Makefiles feed Linuxy linker arguments (-Wl,-rpath==) to the compiler.
> I kludged that by manually editing the Makefile(s) to just use -L././libs instead. Which would seem to be a better solution in general. YMMV.
>
> Could you please fix these for a future release? Thanks.
>
>

Re: userspace-rcu-0.8.6 problems on MacOSX

[Zifei Tong]

Hi,

I tried building urcu on my Yosemite laptop.

On Fri, Mar 13, 2015 at 1:24 AM, Alexandre Montplaisir
<alexmonthy@voxpopuli.im> wrote:
> Hi,
>
> Technically, liburcu is not supported on Mac, but if we can easily make it
> work, why not try!
>
> I tried compiling it on an OS X system (Yosemite, autoconf/automake
> installed from Homebrew), but got many errors like this one:
>
> In file included from wfcqueue.c:26:
>
> ./urcu/static/wfcqueue.h:260:22: error: passing 'struct __cds_wfcq_head *'
> to parameter of incompatible type 'cds_wfcq_head_ptr_t'
>
>         if (_cds_wfcq_empty(head, tail))
>
>                             ^~~~
>
> ./urcu/static/wfcqueue.h:132:56: note: passing argument to parameter
> 'u_head' here
>
> static inline bool _cds_wfcq_empty(cds_wfcq_head_ptr_t u_head,
>
>                                                        ^
>
> What steps did you use to make it compile?

gcc 4.9 from Homebrew works fine. For clang I have to apply a patch to move
'__attribute__((__transparent_union__))' after the union declaration.
I think this
might be a clang bug.

diff --git a/urcu/lfstack.h b/urcu/lfstack.h
index cd8e958..fa58054 100644
--- a/urcu/lfstack.h
+++ b/urcu/lfstack.h
@@ -84,10 +84,10 @@ struct cds_lfs_stack {
  * struct cds_lfs_stack and struct __cds_lfs_stack on any of those two
  * types.
  */
-typedef union __attribute__((__transparent_union__)) {
+typedef union {
  struct __cds_lfs_stack *_s;
  struct cds_lfs_stack *s;
-} cds_lfs_stack_ptr_t;
+} __attribute__((__transparent_union__)) cds_lfs_stack_ptr_t;

 #ifdef _LGPL_SOURCE

diff --git a/urcu/wfcqueue.h b/urcu/wfcqueue.h
index df26e33..9d78d1b 100644
--- a/urcu/wfcqueue.h
+++ b/urcu/wfcqueue.h
@@ -79,10 +79,10 @@ struct cds_wfcq_head {
  * struct cds_wfcq_head and struct __cds_wfcq_head on any of those two
  * types.
  */
-typedef union __attribute__((__transparent_union__)) {
+typedef union {
  struct __cds_wfcq_head *_h;
  struct cds_wfcq_head *h;
-} cds_wfcq_head_ptr_t;
+} __attribute__((__transparent_union__))  cds_wfcq_head_ptr_t;

 struct cds_wfcq_tail {
  struct cds_wfcq_node *p;
diff --git a/urcu/wfstack.h b/urcu/wfstack.h
index 362cacc..3ac3be4 100644
--- a/urcu/wfstack.h
+++ b/urcu/wfstack.h
@@ -97,10 +97,10 @@ struct cds_wfs_stack {
  * struct cds_wfs_stack and struct __cds_wfs_stack on any of those two
  * types.
  */
-typedef union __attribute__((__transparent_union__)) {
+typedef union {
  struct __cds_wfs_stack *_s;
  struct cds_wfs_stack *s;
-} cds_wfs_stack_ptr_t;
+} __attribute__((__transparent_union__))  cds_wfs_stack_ptr_t;

 #ifdef _LGPL_SOURCE

> Cheers,
> Alexandre
>
>
>
> On 2015-03-11 11:50 AM, Jim Reid wrote:
>>
>> Hi. There are some problems getting this to compile on MacOSX (10.9.5):
>>
>> 1) Many of the make regtest tests fail because the time command use
>> command line arguments. eg:
>>
>> ...
>> ./test_urcu_lgc 4 4 10 -d 2 -b 32768
>> /usr/bin/time: illegal option -- a
>> usage: time [-lp] command.
>> ...
>>
>> 2) The generated Makefiles feed Linuxy linker arguments (-Wl,-rpath==) to
>> the compiler.
>> I kludged that by manually editing the Makefile(s) to just use -L././libs
>> instead. Which would seem to be a better solution in general. YMMV.

Apparently, ld in OS X does not support -Wl,-rpath="/foo/bar" syntax,
simply replace '='
with space like -Wl,-rpath "/foo/bar" did the trick. I can send a
patch for this.

Thanks,
Zifei Tong

>> Could you please fix these for a future release? Thanks.
>>
>>
>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: userspace-rcu-0.8.6 problems on MacOSX

[Alexandre Montplaisir]

On 2015-03-13 4:59 AM, Zifei Tong wrote:
>
> [...]
> gcc 4.9 from Homebrew works fine. For clang I have to apply a patch to move
> '__attribute__((__transparent_union__))' after the union declaration.
> I think this
> might be a clang bug.

Indeed, I tested it with clang 3.5 on Linux and it gives the same error 
too. But your patch fixes it (and it keeps working fine with GCC), it 
seems Clang expects the __attribute__ to be after the closing brace. GCC 
accepts both, although they recommend the other way:

(from https://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html )
For an enum, struct or union type, you may specify attributes either 
between the enum, struct or union tag and the name of the type, or just 
past the closing curly brace of the /definition/. The former syntax is 
preferred.


I don't know what the liburcu maintainers prefer, to keep using GCC's 
recommended syntax, or to make it compilable on current Clang?

>
>
>
>>
>>
>> On 2015-03-11 11:50 AM, Jim Reid wrote:
>>> Hi. There are some problems getting this to compile on MacOSX (10.9.5):
>>>
>>> 1) Many of the make regtest tests fail because the time command use
>>> command line arguments. eg:
>>>
>>> ...
>>> ./test_urcu_lgc 4 4 10 -d 2 -b 32768
>>> /usr/bin/time: illegal option -- a
>>> usage: time [-lp] command.
>>> ...

I found the culprit, the scripts tests/benchmark/runtests.sh and 
runtests-batch.sh run "time" with -a -o options, with don't exist on 
OSX's implementation. Changing the script to instead use output 
redirection keeps more or less the same output:

diff --git a/tests/benchmark/runtests-batch.sh b/tests/benchmark/runtests-batch.sh

index 2da1401..3d295fb 100755

--- a/tests/benchmark/runtests-batch.sh

+++ b/tests/benchmark/runtests-batch.sh

@@ -6,7 +6,7 @@ log_file="runall.detail.log"

  

  # Check if time bin is non-empty

  if [ -n "$test_time_bin" ]; then

-       time_command="$test_time_bin -a -o $log_file"

+       time_command="$test_time_bin"

  else

         time_command=""

  fi

@@ -14,6 +14,6 @@ fi

  #for a in test_urcu_gc test_urcu_gc_mb test_urcu_qsbr_gc; do

  for a in test_urcu_gc; do

         echo "./${a} $*" | tee -a "$log_file"

-       $time_command ./${a} $*

+       $time_command ./${a} $* 2>> $log_file

  done



However, by doing so those tests now hang on my Mac test system (whereas 
before they would get skipped). Is it possible those tests don't even 
work on Mac?


>>>
>>> 2) The generated Makefiles feed Linuxy linker arguments (-Wl,-rpath==) to
>>> the compiler.
>>> I kludged that by manually editing the Makefile(s) to just use -L././libs
>>> instead. Which would seem to be a better solution in general. YMMV.
> Apparently, ld in OS X does not support -Wl,-rpath="/foo/bar" syntax,
> simply replace '='
> with space like -Wl,-rpath "/foo/bar" did the trick. I can send a
> patch for this.

Sure, you could send a patch. It keeps working with GNU's ld too, so I 
assume it would be acceptable.


Cheers,
Alexandre

>
> Thanks,
> Zifei Tong
>
>>> Could you please fix these for a future release? Thanks.
>>>
>>>

Re: userspace-rcu-0.8.6 problems on MacOSX

[Mathieu Desnoyers]

----- Original Message -----
> From: "Alexandre Montplaisir" <alexmonthy@voxpopuli.im>
> To: "Zifei Tong" <soariez@gmail.com>, "Jim Reid" <jim@rfc1035.com>
> Cc: lttng-dev@lists.lttng.org, "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> Sent: Friday, March 13, 2015 5:19:37 PM
> Subject: Re: [lttng-dev] userspace-rcu-0.8.6 problems on MacOSX
> 
> 
> 
> On 2015-03-13 4:59 AM, Zifei Tong wrote:
> >
> > [...]
> > gcc 4.9 from Homebrew works fine. For clang I have to apply a patch to move
> > '__attribute__((__transparent_union__))' after the union declaration.
> > I think this
> > might be a clang bug.
> 
> Indeed, I tested it with clang 3.5 on Linux and it gives the same error
> too. But your patch fixes it (and it keeps working fine with GCC), it
> seems Clang expects the __attribute__ to be after the closing brace. GCC
> accepts both, although they recommend the other way:
> 
> (from https://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html )
> For an enum, struct or union type, you may specify attributes either
> between the enum, struct or union tag and the name of the type, or just
> past the closing curly brace of the /definition/. The former syntax is
> preferred.
> 
> 
> I don't know what the liburcu maintainers prefer, to keep using GCC's
> recommended syntax, or to make it compilable on current Clang?
> 

Let's go for clang compatibility. Fixed in:

commit 5135c0fd2284e6365bc9d0c53f060b7e946a412f
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Sun Mar 15 21:02:13 2015 -0400

    Fix: move transparent union attribute after union declaration for clang
    
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

> >
> >
> >
> >>
> >>
> >> On 2015-03-11 11:50 AM, Jim Reid wrote:
> >>> Hi. There are some problems getting this to compile on MacOSX (10.9.5):
> >>>
> >>> 1) Many of the make regtest tests fail because the time command use
> >>> command line arguments. eg:
> >>>
> >>> ...
> >>> ./test_urcu_lgc 4 4 10 -d 2 -b 32768
> >>> /usr/bin/time: illegal option -- a
> >>> usage: time [-lp] command.
> >>> ...
> 
> I found the culprit, the scripts tests/benchmark/runtests.sh and
> runtests-batch.sh run "time" with -a -o options, with don't exist on
> OSX's implementation. Changing the script to instead use output
> redirection keeps more or less the same output:
> 
> diff --git a/tests/benchmark/runtests-batch.sh
> b/tests/benchmark/runtests-batch.sh
> 
> index 2da1401..3d295fb 100755
> 
> --- a/tests/benchmark/runtests-batch.sh
> 
> +++ b/tests/benchmark/runtests-batch.sh
> 
> @@ -6,7 +6,7 @@ log_file="runall.detail.log"
> 
>   
> 
>   # Check if time bin is non-empty
> 
>   if [ -n "$test_time_bin" ]; then
> 
> -       time_command="$test_time_bin -a -o $log_file"
> 
> +       time_command="$test_time_bin"
> 
>   else
> 
>          time_command=""
> 
>   fi
> 
> @@ -14,6 +14,6 @@ fi
> 
>   #for a in test_urcu_gc test_urcu_gc_mb test_urcu_qsbr_gc; do
> 
>   for a in test_urcu_gc; do
> 
>          echo "./${a} $*" | tee -a "$log_file"
> 
> -       $time_command ./${a} $*
> 
> +       $time_command ./${a} $* 2>> $log_file
> 
>   done
> 

Applied as:

commit 8d11f7cd74968f5baffdbfde8b38d3197ef6865d
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Sun Mar 15 21:15:41 2015 -0400

    tests: Use stderr redirection for time output
    
    Allows using Mac OS X time command in tests.
    
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> 
> 
> However, by doing so those tests now hang on my Mac test system (whereas
> before they would get skipped). Is it possible those tests don't even
> work on Mac?

Do they really hang, or just take a very long time to run ?
Can you reproduce this easily ?

> 
> 
> >>>
> >>> 2) The generated Makefiles feed Linuxy linker arguments (-Wl,-rpath==) to
> >>> the compiler.
> >>> I kludged that by manually editing the Makefile(s) to just use -L././libs
> >>> instead. Which would seem to be a better solution in general. YMMV.
> > Apparently, ld in OS X does not support -Wl,-rpath="/foo/bar" syntax,
> > simply replace '='
> > with space like -Wl,-rpath "/foo/bar" did the trick. I can send a
> > patch for this.
> 
> Sure, you could send a patch. It keeps working with GNU's ld too, so I
> assume it would be acceptable.

Fix pushed:

commit 1f2b013ddbde8634c3b3eda921970e37a21ba297
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Sun Mar 15 21:09:15 2015 -0400

    Fix: use space after rpath for OS X ld
    
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Thanks!

Mathieu

> 
> 
> Cheers,
> Alexandre
> 
> >
> > Thanks,
> > Zifei Tong
> >
> >>> Could you please fix these for a future release? Thanks.
> >>>
> >>>
> 
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: userspace-rcu-0.8.6 problems on MacOSX

[Alexandre Montplaisir]

Thanks Mathieu! With all the latest fixes, liburcu master can now 
compile as-is on Mac.


On 2015-03-15 9:17 PM, Mathieu Desnoyers wrote:
>
>> However, by doing so those tests now hang on my Mac test system (whereas
>> before they would get skipped). Is it possible those tests don't even
>> work on Mac?
> Do they really hang, or just take a very long time to run ?
> Can you reproduce this easily ?
>
>

Quite reproducible, yes. I let 'make regtest' run for a couple hours, 
and it stuck at:

cd ../benchmark && ./runall.sh && cd ..
Executing batch RCU test
./test_urcu_gc 4 4 10 -d 0 -b 1


Running the last command by hand also hangs. It's using very little CPU 
in both cases.

Re: userspace-rcu-0.8.6 problems on MacOSX

[Mathieu Desnoyers]

----- Original Message -----
> 
> Thanks Mathieu! With all the latest fixes, liburcu master can now
> compile as-is on Mac.
> 
> 
> On 2015-03-15 9:17 PM, Mathieu Desnoyers wrote:
> >
> >> However, by doing so those tests now hang on my Mac test system (whereas
> >> before they would get skipped). Is it possible those tests don't even
> >> work on Mac?
> > Do they really hang, or just take a very long time to run ?
> > Can you reproduce this easily ?
> >
> >
> 
> Quite reproducible, yes. I let 'make regtest' run for a couple hours,
> and it stuck at:
> 
> cd ../benchmark && ./runall.sh && cd ..
> Executing batch RCU test
> ./test_urcu_gc 4 4 10 -d 0 -b 1
> 
> 
> Running the last command by hand also hangs. It's using very little CPU
> in both cases.

Here is the fix.

commit db21eff94739900b1ab51d231dfb281ead0a0fa5
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Tue Mar 17 17:53:21 2015 -0400

    Fix: compat_futex_noasync race condition
    
    The Userspace RCU compatibility layer around sys_futex has a race
    condition which makes pretty much all "benchmark" tests hang pretty
    quickly on non-Linux systems (tested on Mac OS X).
    
    I narrowed it down to a bug in compat_futex_noasync: this compat layer
    uses a single pthread mutex and condition variable for all callers,
    independently of their uaddr. The FUTEX_WAKE performs a pthread cond
    broadcast to all waiters. FUTEX_WAIT must then compare *uaddr with val
    to see which thread has been awakened.
    
    Unfortunately, the check was not done again after each return from
    pthread_cond_wait(), thus causing the race.
    
    This race affects threads using the futex_noasync() compatibility layer
    concurrently, thus it affects only on non-Linux systems.
    
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

It's in master, backported to stable-0.7 and stable-0.8.

We really need to gear up our CI with MacOSX support. I just bought
a mac mini for this purpose.

Thanks for the testing!

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

userspace-rcu-0.8.6 problems on MacOSX

[Jim Reid]

Hi. There are some problems getting this to compile on MacOSX (10.9.5):

1) Many of the make regtest tests fail because the time command use command line arguments. eg:

...
./test_urcu_lgc 4 4 10 -d 2 -b 32768
/usr/bin/time: illegal option -- a
usage: time [-lp] command.
...

2) The generated Makefiles feed Linuxy linker arguments (-Wl,-rpath==) to the compiler.
I kludged that by manually editing the Makefile(s) to just use -L././libs instead. Which would seem to be a better solution in general. YMMV.

Could you please fix these for a future release? Thanks.