Page 9 of 9

Re: C++ wrappers

Posted: Tue Jan 30, 2018 8:37 pm
by szekelyisz
Korken,

What's the reason for declaring most of the classes final? IMHO it takes out the elegancy from interfacing ChibiOS with C++. For example, with the old wrapper you could derive a class from BaseStaticThread, define a main() member function and call any thread-related function implicitly against the this pointer. Now you have to store a reference to the Thread object and prefix all calls with that member. For now I don't see a reason why these classes need to be final. Without that you would still have the freedom to choose between inheritance or referencing.

Thanks, Szabi

Re: C++ wrappers

Posted: Fri Feb 02, 2018 10:45 am
by Korken
szekelyisz wrote:Korken,

What's the reason for declaring most of the classes final? IMHO it takes out the elegancy from interfacing ChibiOS with C++. For example, with the old wrapper you could derive a class from BaseStaticThread, define a main() member function and call any thread-related function implicitly against the this pointer. Now you have to store a reference to the Thread object and prefix all calls with that member. For now I don't see a reason why these classes need to be final. Without that you would still have the freedom to choose between inheritance or referencing.

Thanks, Szabi

This comes from the changes made in the beginning of these new wrappers, and I had the same question as you.
But helmut had good points about it: viewtopic.php?f=3&t=3287&start=50#p27048

Also, your should really not be using virtual inheritance any more. There is a really good talk on YouTube from one of the latest C++ conferences, I will try to find it.
Use a std::variant for all supported types instead or CRTP, I have yet to find a case where I really needed virtual inheritance in embedded.

However, if a use case is found that cannot be within this style, please provide it and we can look at updating the interface.

Re: C++ wrappers

Posted: Sun Dec 30, 2018 8:54 pm
by rbarreiros
Hi,

I'm having a problem with the latest trunk, I have a class and a callback typedef like this:

Code: Select all

typedef void (*MyCbFunction)(int);

class MyClass
{
   public:
      MyClass();
      void somefunc(void);
   private:
      MyCbFunction _cb;
}

----

MyClass::somefunc(void)
{
   // Do stuff, have some pointer func point to _cb etc
   if(_cb != NULL)
      _cb(10);
}



I already have os/various/syscalls.c and syscalls_cpp.cpp being compiled in the Makefile.

I skipped most of the obvious stuff, of course the pointer is init with NULL, there's methods to set it, etc, but whenever I call the callback in the c++ method, I get:

Code: Select all

/usr/local/Cellar/arm-none-eabi-gcc/20180627/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/libg.a(lib_a-abort.o): In function `abort':
abort.c:(.text.abort+0xa): undefined reference to `_exit'
/usr/local/Cellar/arm-none-eabi-gcc/20180627/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/libg.a(lib_a-signalr.o): In function `_kill_r':
signalr.c:(.text._kill_r+0x10): undefined reference to `_kill'
/usr/local/Cellar/arm-none-eabi-gcc/20180627/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/libg.a(lib_a-signalr.o): In function `_getpid_r':
signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'
collect2: error: ld returned 1 exit status


using OSX

Code: Select all

Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/Cellar/arm-none-eabi-gcc/20180627/bin/../lib/gcc/arm-none-eabi/7.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: /Users/build/work/GCC-7-build/src/gcc/configure --target=arm-none-eabi --prefix=/Users/build/work/GCC-7-build/install-native --libexecdir=/Users/build/work/GCC-7-build/install-native/lib --infodir=/Users/build/work/GCC-7-build/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/Users/build/work/GCC-7-build/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/Users/build/work/GCC-7-build/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/Users/build/work/GCC-7-build/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/Users/build/work/GCC-7-build/install-native/arm-none-eabi --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --with-gmp=/Users/build/work/GCC-7-build/build-native/host-libs/usr --with-mpfr=/Users/build/work/GCC-7-build/build-native/host-libs/usr --with-mpc=/Users/build/work/GCC-7-build/build-native/host-libs/usr --with-isl=/Users/build/work/GCC-7-build/build-native/host-libs/usr --with-libelf=/Users/build/work/GCC-7-build/build-native/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-lstdc++ -lm' --with-pkgversion='GNU Tools for Arm Embedded Processors 7-2018-q2-update' --with-multilib-list=rmprofile
Thread model: single
gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q2-update)


Any hint of what I must be doing wrong ?

Re: C++ wrappers

Posted: Sun Dec 30, 2018 10:08 pm
by Giovanni
Hi,

Strange, those are in syscalls_cpp.cpp, are you sure the module is linked with the application? try disabling the linker garbage collection and/or LTO.

Giovanni

Re: C++ wrappers

Posted: Sun Dec 30, 2018 10:28 pm
by rbarreiros
It linked with -fno-lto, but --no-gc-sections (with or without) made no changes.
Note that I had to add syscalls.c to the make file, and of course, syscalls_cpp.cpp is added from chcpp.mk