1. 02 Apr, 2017 3 commits
  2. 01 Apr, 2017 1 commit
  3. 22 Mar, 2017 1 commit
    • Philippe Gerum's avatar
      boilerplate/setup: postpone detection of late setup calls · 2353e59f
      Philippe Gerum authored
      Since #d6d8047e, setup descriptors may be registered after the base
      inits have been performed, if DSO bootstrap modules were activated.
      Postpone the detection of late setup calls after the main bootstrap
      module has run instead.
      
      This fixes an issue with --enable-assert in presence of DSO bootstrap
      code.
      2353e59f
  4. 21 Mar, 2017 1 commit
    • Philippe Gerum's avatar
      boilerplate/setup: allow DSO bootstrap modules to coexist with main one · d6d8047e
      Philippe Gerum authored
      Gluing a PIC bootstrap module to a DSO is a common way to start the
      Xenomai services before constructors of static C++ objects
      instantiated by the DSO and which depend on such services, are
      invoked.
      
      With such module present in the DSO, a Cobalt-based application
      process would attach itself to the Cobalt core via the bootstrapping
      sequence, enabling the real-time services for the whole process,
      including the static C++ constructors which may be invoked when
      attaching the shared object.
      
      e.g. in libfoo.so:
      
      class FOO {
      protected:
      	sem_t sem;
      public:
      	static FOO bar;
      };
      
      ...
      
      FOO FOO::bar;
      
      FOO::FOO()
      {
      	// Initialize a Cobalt semaphore
      	sem_init(&sem, 0, 0);
      }
      
      However, adding a bootstrap module to a DSO currently prevents from
      merging a second bootstrap module aimed at kickstarting the main
      program's setup code and early inits, due to conflicting symbols and
      the restriction on invoking xenomai_init() only once for any given
      process.
      
      The changes introduce a DSO-specific initialization service
      (xenomai_init_dso()), which may be called from the context of the
      dynamic linker attaching a shared object to the current
      executable. The DSO-specific bootstrap module - if present - will call
      xenomai_init_dso(), there is no restriction on the number of DSOs
      calling this service.
      
      The non-DSO bootstrap module invokes xenomai_init() as previously, for
      kickstarting the main program's early inits.
      d6d8047e
  5. 15 Mar, 2017 3 commits
    • Philippe Gerum's avatar
      lib/cobalt: modechk: do not wrap cxa* API · 6f8dc4d9
      Philippe Gerum authored
      6f8dc4d9
    • Philippe Gerum's avatar
      b326c59d
    • Philippe Gerum's avatar
      lib/cobalt: modechk: switch to shared object, drop cxa wrappers · 8c82454c
      Philippe Gerum authored
      Dynamically linked code from shared libraries which may reference mode
      checking wrappers cannot depend on symbols which are only visible from
      the static link phase, such as those defined by the libmodechk.a
      library. Otherwise, unresolved references to symbols from libmodechk.a
      may exist in shared objects such as libcopperplate.so.
      
      Unfortunately, we can't interpose on the cxa* API from a dynamic
      library, since the latter would create references to "real"
      __cxa_acquire/release/abort() routines, which are not available from
      plain C builds since only libstdc++ defines them.
      
      Providing placeholders for the cxa* API calls in a dynamic object is
      not an option either, since that would create a dependency on the link
      order between libmodechk and libstdc++ for pulling the actual symbols
      instead of the dummy ones, which is not acceptable. Besides, relying
      on LD_DYNAMIC_WEAK is fragile, unpractical, and won't work in secured
      execution mode.
      
      To work around this chicken-and-egg issue, make libmodechk a shared
      object, and drop mode checking for the cxa* API for now. We'll revisit
      the issue of enabling back the cxa* API later.
      8c82454c
  6. 13 Mar, 2017 5 commits
  7. 12 Mar, 2017 3 commits
  8. 05 Mar, 2017 1 commit
  9. 04 Mar, 2017 1 commit
  10. 03 Mar, 2017 1 commit
  11. 22 Feb, 2017 2 commits
  12. 17 Feb, 2017 1 commit
  13. 15 Feb, 2017 4 commits
  14. 11 Feb, 2017 1 commit
  15. 10 Feb, 2017 1 commit
  16. 27 Jan, 2017 1 commit
    • Philippe Gerum's avatar
      boilerplate/tlsf: work around excessive meta-data overhead for main pool · 00e3d016
      Philippe Gerum authored
      e0e6ae76 caused a regression with failure to initialize the main pool
      with TLSF, uncovering an issue in the allocator code which fails to
      account properly for the overhead induced by the meta-data.
      
      Overhead footprints and management is a recurring problem with TLSF,
      particularly on 64bit platforms; for this reason there is a plan for
      dropping TLSF entirely from the Xenomai code base. Until this happens,
      the current change works around the issue to keep things going.
      00e3d016
  17. 26 Jan, 2017 5 commits
  18. 12 Jan, 2017 1 commit
  19. 03 Jan, 2017 1 commit
  20. 31 Dec, 2016 1 commit
    • Maciej Sumiński's avatar
      testsuite/cyclictest: silence UMR false-positive with GCC 6.x · 3fa7c63c
      Maciej Sumiński authored
      cyclictest.c: In function ‘timerthread’:
      cyclictest.c:347:30: error: ‘*((void *)&stop+8)’ may be used
      uninitialized in this function [-Werror=maybe-uninitialized]
        diff += ((int) t1.tv_nsec - (int) t2.tv_nsec) / 1000;
                                    ^~~~~~~~~~~~~~~~
      cyclictest.c:760:39: note: ‘*((void *)&stop+8)’ was declared here
        struct timespec now, next, interval, stop;
                                             ^~~~
      cyclictest.c:346:54: error: ‘stop.tv_sec’ may be used uninitialized in
      this function [-Werror=maybe-uninitialized]
        diff = USEC_PER_SEC * (long long)((int) t1.tv_sec - (int) t2.tv_sec);
                                                            ^~~~~~~~~~~~~~~
      cyclictest.c:760:39: note: ‘stop.tv_sec’ was declared here
        struct timespec now, next, interval, stop;
                                             ^~~~
      3fa7c63c
  21. 28 Dec, 2016 1 commit
  22. 27 Dec, 2016 1 commit
    • Jan Kiszka's avatar
      cobalt/kernel: Allow to restart clock_nanosleep and select after signal processing · 36132cdb
      Jan Kiszka authored
      Only if a signal was actually delivered to a thread that was blocked on
      sleep, [clock_]nanosleep or select, those calls should return -EINTR.
      Otherwise, they should resume with the timeout, accordingly adjusted in
      case of relative timeout. So far we returned -EINTR immediately which
      particularly disturbed the debugging of applications (SIGSTOP/CONT
      terminated those syscalls).
      
      This approach reuses the Linux restart mechanism to find out if those
      syscalls should be restarted or actually terminated after the signal
      was handled: Linux sets current->restart_block.fn in case a termination
      is required, unconditionally, thus also when the syscall did not return
      ERESTART_RESTARTBLOCK. We also use the restart_block.nanosleep.expires
      to transfer the remaining timeout to the restarted syscall.
      
      We can't use the original restart mechanism of Linux because it directs
      all ERESTART_RESTARTBLOCK through a special, Linux-only syscall. In our
      case, we would have to migrate the caller in that context to primary in
      order to resume the sleep, but this is not possible under Xenomai (we
      need to migration from within the syscall hooks).
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      36132cdb