Re: Freestanding and Hosted implementations.
On 12/05/2014 07:11 PM, Fernando Alberione wrote: Hello, I'm making a research about embbedded OS that are using C++ compilers. Particularly I need to know: 1) Are you using a freestanding or hosted implementation of the C++ library headers? I mean, how do you define the macro __STDC_HOSTED__? By default the RTEMS tool chain uses a hosted environment. 2) What C++ and C library headers are you currently supplying, since there are some of them that are not required on the standard (e.g.: iostream, exception, array, thread)? I think nobody tested std::thread so far, but it should work out of the box since it likely uses pthread for its implementation. These question are related with the toolchains that you provide. Thanks in advance! Best regards. Fernando Alberione Software Engineer Taller Technologies - Argentina San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina *Mobile:* [+54 358 4827823 (ARG)] *Skype:* falberione ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: duplicate functionality in libmd and libcrypt
Hello Gedare, where did you spot duplicated functionality in these libraries (both end up in librtemscpu.a)? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: duplicate functionality in libmd and libcrypt
Looks like I wrote carelessly. I see different now. libcrypt supports the "crypt" commands while libmd provides some cryptographic hash functions. The file names led me to believe there was some overlap. README might be nice in those subdirectories. On this topic, libmd should be renamed now that it contains cryptographic hash functions other than md4 and md5. And does crypt deserve its own subdirectory, or should it more appropriately go under libcsupport? -Gedare On Sat, Dec 6, 2014 at 4:24 AM, Sebastian Huber wrote: > Hello Gedare, > > where did you spot duplicated functionality in these libraries (both end up > in librtemscpu.a)? > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Freestanding and Hosted implementations.
On 12/06/2014 03:23 AM, Sebastian Huber wrote: On 12/05/2014 07:11 PM, Fernando Alberione wrote: Hello, I'm making a research about embbedded OS that are using C++ compilers. Particularly I need to know: 1) Are you using a freestanding or hosted implementation of the C++ library headers? I mean, how do you define the macro __STDC_HOSTED__? By default the RTEMS tool chain uses a hosted environment. 2) What C++ and C library headers are you currently supplying, since there are some of them that are not required on the standard (e.g.: iostream, exception, array, thread)? I think nobody tested std::thread so far, but it should work out of the box since it likely uses pthread for its implementation. We are using GCC's C++ libraries with no tailoring. So everything should just work or be broken just like on Linux. From a high level viewpoint: + RTEMS C++ support == GCC's C++ support + RTEMS C library support is newlib's plus some and should be near complete + RTEMS POSIX support is newlib's plus a lot There are still POSIX methods possible to have on RTEMS missing but the list is shrinking. There is a small set also missing on Cygwin which are showing up slowly in newlib. There are a few POSIX 2008 pthread methods (2?) we don't have yet. If you have precise questions, we would have to see if GCC supports it or newlib/RTEMS. But that's the general status. We use respectable, full featured upstream sources, port them and layer on our threads and other missing pieces. --joel These question are related with the toolchains that you provide. Thanks in advance! Best regards. Fernando Alberione Software Engineer Taller Technologies - Argentina San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina *Mobile:* [+54 358 4827823 (ARG)] *Skype:* falberione ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS SMP configuration
Hi, Thanks Joel and Gedare. I found it a bit tricky as I had to add epiphany to (hidden) aclocal/enable-smp.m4 files at c/src, cpukit and the root directory. It now builds and compiles fine, and actually I can send some SMP messages to RTEMS on another core, but the current status of SMP/epiphany port is in its very early stages, and need more work. Regards, Hesham On Fri, Dec 5, 2014 at 10:31 PM, Joel Sherrill wrote: > > > On December 5, 2014 2:40:59 PM CST, Hesham Moustafa > wrote: >>On Fri, Dec 5, 2014 at 8:36 PM, Gedare Bloom wrote: >>> Look for where the undefined functions exist and see what guards in >>> the build system or the source code itself might be precluding them >>> from your build. >>> >>Most of SMP files are guarded with HAS_SMP and RTEMS_SMP. I always run >>boostrap -p and bootstrap after every change and configure/build >>again. >>> Make sure you re-bootstrap and re-configure a clean build, as old >>> files might cause problems. > > Reference the SPARC leon3 bsp and keep good notes. They can be vetted against > documentation or become it. > > The SMP wiki page may have hints as well. > > >>> -Gedare >>> >>> On Fri, Dec 5, 2014 at 3:09 PM, Hesham Moustafa >>> wrote: It seems like adding an entry for epiphany at aclocal/enable-smp.m4 >>is not enough, I still get the same error, any hints? On Fri, Dec 5, 2014 at 6:03 PM, Hesham Moustafa wrote: > I had to add epiphany to the list RTEMS CPUs that support SMP at > aclocal/enable-smp.m4 > > On Fri, Dec 5, 2014 at 5:06 PM, Hesham Moustafa > wrote: >> Hi, >> >> Should I add anything other than --enable-smp at configuration >>line >> and RTEMS_CHECK_SMP >> AM_CONDITIONAL(HAS_SMP,[test "$rtems_cv_HAS_SMP" = "yes"]) >> to bsp configure.ac file to make the building system collects SMP >> files (e.g, smpimpl.h). I always get undefined reference to some >>SMP >> functions like _SMP_Send_message although I am including >> >> >> Thanks, >> Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel >>___ >>devel mailing list >>devel@rtems.org >>http://lists.rtems.org/mailman/listinfo/devel > > --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
