[Xenomai] c++11 issue

[Xenomai] c++11 issue

[Cris Almaraz]

Hi all,

I have a problem similar to the one described in
https://xenomai.org/pipermail/xenomai/2018-February/038373.html.

Compiling with -std=c++11 and adding the headers:
    #include <xenomai/init.h>
    #include <xenomai/tunables.h>

Error extract:
In file included from /usr/xenomai/include/xenomai/tunables.h:21:0,
                 from myApplication.cpp:
/usr/xenomai/include/boilerplate/tunables.h:72:15: error: variable or
field ‘__assign_cpu_affinity_config’ declared void  static inline
define_config_tunable(cpu_affinity, cpu_set_t, cpus)
               ^
/usr/xenomai/include/boilerplate/tunables.h:72:15: error: expected
primary-expression before ‘)’ token  static inline
define_config_tunable(cpu_affinity, cpu_set_t, cpus) ...

Do you have any ideas how to solve the issue? I noticed that there is
no answer for the previous mail.

Thank you in advance and best regards,
Cristina.

System configuration:
Xenomai 3.0.9 Core Mercury
CentOS 7.4

[PATCH] boilerplate: Fix bogus "typeof(type)" in macros

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

This was ignored by most compilers so far, but it breaks at least under
c++11.

Reported-by: Stéphane Ancelot <sancelot@numalliance.com>
Reported-by: Cris Almaraz <cristina.almaraz@gmail.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

Thanks for reporting (and sorry for the long patch delay). This should
fix it.

 include/boilerplate/tunables.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/boilerplate/tunables.h b/include/boilerplate/tunables.h
index db8523be67..38f414e455 100644
--- a/include/boilerplate/tunables.h
+++ b/include/boilerplate/tunables.h
@@ -37,10 +37,10 @@ static inline int __may_change_config_tunable(void)
 	__read_ ## __name ## _ ## __scope

 #define __define_tunable(__name, __type, __val, __scope)	\
-	void __tunable_set_call(__name, __scope)(typeof(__type) __val)
+	void __tunable_set_call(__name, __scope)(__type __val)

 #define __read_tunable(__name, __type, __scope)	\
-	typeof(__type) __tunable_get_call(__name, __scope)(void)
+	__type __tunable_get_call(__name, __scope)(void)

 #define define_config_tunable(__name, __type, __val)	\
 	__define_tunable(__name, __type, __val, config)
--
2.16.4

Re: [PATCH] boilerplate: Fix bogus "typeof(type)" in macros

[Philippe Gerum]

On 7/10/19 9:39 PM, Jan Kiszka via Xenomai wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> This was ignored by most compilers so far, but it breaks at least under
> c++11.

This was hardly ignored since this evaluates to a required type
information, the issue is rather with typeof() belonging to the GNU
extension set. Building with -std=gnu++11 solves that issue with the
current implementation which generally assumes those extensions are enabled.

> 
> Reported-by: Stéphane Ancelot <sancelot@numalliance.com>
> Reported-by: Cris Almaraz <cristina.almaraz@gmail.com>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> 
> Thanks for reporting (and sorry for the long patch delay). This should
> fix it.
> 
>  include/boilerplate/tunables.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/boilerplate/tunables.h b/include/boilerplate/tunables.h
> index db8523be67..38f414e455 100644
> --- a/include/boilerplate/tunables.h
> +++ b/include/boilerplate/tunables.h
> @@ -37,10 +37,10 @@ static inline int __may_change_config_tunable(void)
>  	__read_ ## __name ## _ ## __scope
> 
>  #define __define_tunable(__name, __type, __val, __scope)	\
> -	void __tunable_set_call(__name, __scope)(typeof(__type) __val)
> +	void __tunable_set_call(__name, __scope)(__type __val)
> 
>  #define __read_tunable(__name, __type, __scope)	\
> -	typeof(__type) __tunable_get_call(__name, __scope)(void)
> +	__type __tunable_get_call(__name, __scope)(void)
> 
>  #define define_config_tunable(__name, __type, __val)	\
>  	__define_tunable(__name, __type, __val, config)
> --


That won't work with non-trivial type expr like this one:

int (*foo_handler)(void);

define_config_tunable(foobar, int (*)(void), handler)
{
	foo_handler = handler;
}

And we have those in the field already.

-- 
Philippe.

Re: [PATCH] boilerplate: Fix bogus "typeof(type)" in macros

[Jan Kiszka]

On 10.07.19 22:50, Philippe Gerum wrote:
> On 7/10/19 9:39 PM, Jan Kiszka via Xenomai wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> This was ignored by most compilers so far, but it breaks at least under
>> c++11.
>
> This was hardly ignored since this evaluates to a required type
> information, the issue is rather with typeof() belonging to the GNU
> extension set. Building with -std=gnu++11 solves that issue with the
> current implementation which generally assumes those extensions are enabled.

If these two cases are the only ones that prevent standard-conforming builds ouf
our external headers, I would be in favor of overcoming that limitation. But if
it should be just the tip of the iceberg, it's likely not worth it.

>
>>
>> Reported-by: Stéphane Ancelot <sancelot@numalliance.com>
>> Reported-by: Cris Almaraz <cristina.almaraz@gmail.com>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>
>> Thanks for reporting (and sorry for the long patch delay). This should
>> fix it.
>>
>>  include/boilerplate/tunables.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/boilerplate/tunables.h b/include/boilerplate/tunables.h
>> index db8523be67..38f414e455 100644
>> --- a/include/boilerplate/tunables.h
>> +++ b/include/boilerplate/tunables.h
>> @@ -37,10 +37,10 @@ static inline int __may_change_config_tunable(void)
>>  	__read_ ## __name ## _ ## __scope
>>
>>  #define __define_tunable(__name, __type, __val, __scope)	\
>> -	void __tunable_set_call(__name, __scope)(typeof(__type) __val)
>> +	void __tunable_set_call(__name, __scope)(__type __val)
>>
>>  #define __read_tunable(__name, __type, __scope)	\
>> -	typeof(__type) __tunable_get_call(__name, __scope)(void)
>> +	__type __tunable_get_call(__name, __scope)(void)
>>
>>  #define define_config_tunable(__name, __type, __val)	\
>>  	__define_tunable(__name, __type, __val, config)
>> --
>
>
> That won't work with non-trivial type expr like this one:
>
> int (*foo_handler)(void);
>
> define_config_tunable(foobar, int (*)(void), handler)
> {
> 	foo_handler = handler;
> }
>
> And we have those in the field already.
>

Out of tree? I didn't find any in-tree build issues.

Jan

[PATCH v2] boilerplate: Fix non-conforming usage of typeof in interface, headers

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

This fixes build breakages when using standard-conforming build, e.g.
-std=c++11.

Reported-by: Stéphane Ancelot <sancelot@numalliance.com>
Reported-by: Cris Almaraz <cristina.almaraz@gmail.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

This should make everyone happy.

 include/boilerplate/tunables.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/boilerplate/tunables.h b/include/boilerplate/tunables.h
index db8523be67..397ffc8939 100644
--- a/include/boilerplate/tunables.h
+++ b/include/boilerplate/tunables.h
@@ -37,10 +37,10 @@ static inline int __may_change_config_tunable(void)
 	__read_ ## __name ## _ ## __scope

 #define __define_tunable(__name, __type, __val, __scope)	\
-	void __tunable_set_call(__name, __scope)(typeof(__type) __val)
+	void __tunable_set_call(__name, __scope)(__typeof__(__type) __val)

 #define __read_tunable(__name, __type, __scope)	\
-	typeof(__type) __tunable_get_call(__name, __scope)(void)
+	__typeof__(__type) __tunable_get_call(__name, __scope)(void)

 #define define_config_tunable(__name, __type, __val)	\
 	__define_tunable(__name, __type, __val, config)
--
2.16.4

Re: [PATCH] boilerplate: Fix bogus "typeof(type)" in macros

[Cris Almaraz]

Thank you for the fast answers!

Enabling the extensions ( - -std=gnu++11) has fixed the issue for me.

Anyhow, I noticed that I still cannot use the set_config_tunable() to
set the mem_pool_size. I configure it as described below, but I still
get the warning

WARNING: [APP] heapobj_init() failed for xxx bytes, raise --mem-pool-size?

If I use the command line option  --mem-pool-size it works without any
issues, but I´d like to include it in the code.

Also, as secondary issue, I cannot use the syntax of 1G to define the
size, as G is not defined (error below). That´s why I have the "GBYTE"
definition.

error: unable to find numeric literal operator ‘operator"" G’

#define GBYTE (1024*1024*1024)
static int my_tune(void){
    set_config_tunable(mem_pool_size, 1*GBYTE);
    printf("mem pool size=%ld\n",get_config_tunable(mem_pool_size));
    return 0;
}

static struct setup_descriptor my_setup = {
    .name = "mySetup",
    .tune = my_tune,	
};

user_setup_call(my_setup);

Any ideas on these points?

Thank you in advance and regards,
Cristina.


El mié., 10 jul. 2019 23:43, Jan Kiszka <jan.kiszka@web.de> escribió:
>
> On 10.07.19 22:50, Philippe Gerum wrote:
> > On 7/10/19 9:39 PM, Jan Kiszka via Xenomai wrote:
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >> This was ignored by most compilers so far, but it breaks at least under
> >> c++11.
> >
> > This was hardly ignored since this evaluates to a required type
> > information, the issue is rather with typeof() belonging to the GNU
> > extension set. Building with -std=gnu++11 solves that issue with the
> > current implementation which generally assumes those extensions are enabled.
>
> If these two cases are the only ones that prevent standard-conforming builds ouf
> our external headers, I would be in favor of overcoming that limitation. But if
> it should be just the tip of the iceberg, it's likely not worth it.
>
> >
> >>
> >> Reported-by: Stéphane Ancelot <sancelot@numalliance.com>
> >> Reported-by: Cris Almaraz <cristina.almaraz@gmail.com>
> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >> ---
> >>
> >> Thanks for reporting (and sorry for the long patch delay). This should
> >> fix it.
> >>
> >>  include/boilerplate/tunables.h | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/boilerplate/tunables.h b/include/boilerplate/tunables.h
> >> index db8523be67..38f414e455 100644
> >> --- a/include/boilerplate/tunables.h
> >> +++ b/include/boilerplate/tunables.h
> >> @@ -37,10 +37,10 @@ static inline int __may_change_config_tunable(void)
> >>      __read_ ## __name ## _ ## __scope
> >>
> >>  #define __define_tunable(__name, __type, __val, __scope)    \
> >> -    void __tunable_set_call(__name, __scope)(typeof(__type) __val)
> >> +    void __tunable_set_call(__name, __scope)(__type __val)
> >>
> >>  #define __read_tunable(__name, __type, __scope)     \
> >> -    typeof(__type) __tunable_get_call(__name, __scope)(void)
> >> +    __type __tunable_get_call(__name, __scope)(void)
> >>
> >>  #define define_config_tunable(__name, __type, __val)        \
> >>      __define_tunable(__name, __type, __val, config)
> >> --
> >
> >
> > That won't work with non-trivial type expr like this one:
> >
> > int (*foo_handler)(void);
> >
> > define_config_tunable(foobar, int (*)(void), handler)
> > {
> >       foo_handler = handler;
> > }
> >
> > And we have those in the field already.
> >
>
> Out of tree? I didn't find any in-tree build issues.
>
> Jan

Re: [PATCH] boilerplate: Fix bogus "typeof(type)" in macros

[Jan Kiszka]

On 11.07.19 13:19, Cris Almaraz via Xenomai wrote:
> Thank you for the fast answers!
> 
> Enabling the extensions ( - -std=gnu++11) has fixed the issue for me.
> 
> Anyhow, I noticed that I still cannot use the set_config_tunable() to
> set the mem_pool_size. I configure it as described below, but I still
> get the warning
> 
> WARNING: [APP] heapobj_init() failed for xxx bytes, raise --mem-pool-size?
> 
> If I use the command line option  --mem-pool-size it works without any
> issues, but I´d like to include it in the code.

You may call set_config_tunable too late, after __config_done was set to 1.

> 
> Also, as secondary issue, I cannot use the syntax of 1G to define the
> size, as G is not defined (error below). That´s why I have the "GBYTE"
> definition.
> 
> error: unable to find numeric literal operator ‘operator"" G’
> 
> #define GBYTE (1024*1024*1024)
> static int my_tune(void){
>     set_config_tunable(mem_pool_size, 1*GBYTE);
>     printf("mem pool size=%ld\n",get_config_tunable(mem_pool_size));
>     return 0;
> }
> 
> static struct setup_descriptor my_setup = {
>     .name = "mySetup",
>     .tune = my_tune,	
> };
> 
> user_setup_call(my_setup);
> 
> Any ideas on these points?
> 

Please share complete reproduction cases with build instructions. I can't
reproduce the issues based on the above information.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH] boilerplate: Fix bogus "typeof(type)" in macros

[Cris Almaraz]

Hello again,

as I was extracting the code to post it I found the issue with the
set_config_tunable call: my application is including a shared library
that also uses Xenomai and contains the --auto-init-solib flag. Even
when the library does not set any tunable, I guess that it is creating
some conflict at the start of the application. Excluding the library
(that is luckily no longer needed by my program) has solved the issue
for me.

For the syntax issue (not being able to use 1G to define the size),
you can find below the code that I am issuing as test. I guess that
there is an include missing somewhere:

#include <cstdio>
#include <unistd.h>
#include <sys/mman.h>
#include <xenomai/init.h>
#include <xenomai/tunables.h>
#include <alchemy/heap.h>

static int my_tune(void)
{
    //set_config_tunable(mem_pool_size, 1*1024*1024*1024);
    set_config_tunable(mem_pool_size, 1G);
    printf("mem pool size=%ld\n",get_config_tunable(mem_pool_size));
    return 0;
}

static struct setup_descriptor my_setup = {
    .name = "setup-test",
    .tune = my_tune,
};

user_setup_call(my_setup);

int main() {
    mlockall(MCL_CURRENT | MCL_FUTURE);
    RT_HEAP heap_desc;
    rt_heap_create(&heap_desc, "myHeap", 60000000, H_SINGLE);
    rt_heap_delete(&heap_desc);
    return 0;
}

Build commands:
g++ -I/usr/xenomai/include -O0 -g3 -Wall --std=gnu++11 -c
-fmessage-length=0 -I/usr/xenomai/include/mercury
-I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT
-fasynchronous-unwind-tables -D__MERCURY__
-I/usr/xenomai/include/alchemy -MMD -MP -MF"testXeno3.d"
-MT"testXeno3.o" -o "testXeno3.o" "testXeno3.cpp"

g++ -Wl,--no-as-needed -lalchemy  -lcopperplate
/usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main
-Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib
-lmercury -lpthread -lrt -o "testXeno3"  testXeno3.o

As system configuration, I am using Xenomai 3.0.9 Core Mercury over CentOS 7.4

Thanks again for your time and regards,
Cristina.




On 7/12/19, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 11.07.19 13:19, Cris Almaraz via Xenomai wrote:
>> Thank you for the fast answers!
>>
>> Enabling the extensions ( - -std=gnu++11) has fixed the issue for me.
>>
>> Anyhow, I noticed that I still cannot use the set_config_tunable() to
>> set the mem_pool_size. I configure it as described below, but I still
>> get the warning
>>
>> WARNING: [APP] heapobj_init() failed for xxx bytes, raise
>> --mem-pool-size?
>>
>> If I use the command line option  --mem-pool-size it works without any
>> issues, but I´d like to include it in the code.
>
> You may call set_config_tunable too late, after __config_done was set to 1.
>
>>
>> Also, as secondary issue, I cannot use the syntax of 1G to define the
>> size, as G is not defined (error below). That´s why I have the "GBYTE"
>> definition.
>>
>> error: unable to find numeric literal operator ‘operator"" G’
>>
>> #define GBYTE (1024*1024*1024)
>> static int my_tune(void){
>>     set_config_tunable(mem_pool_size, 1*GBYTE);
>>     printf("mem pool size=%ld\n",get_config_tunable(mem_pool_size));
>>     return 0;
>> }
>>
>> static struct setup_descriptor my_setup = {
>>     .name = "mySetup",
>>     .tune = my_tune,	
>> };
>>
>> user_setup_call(my_setup);
>>
>> Any ideas on these points?
>>
>
> Please share complete reproduction cases with build instructions. I can't
> reproduce the issues based on the above information.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>