1. 19 Mar, 2020 7 commits
    • Philippe Gerum's avatar
      build: catch obviously wrong UAPI setting · 865d8f62
      Philippe Gerum authored
    • Philippe Gerum's avatar
      lib/init: better detect ABI discrepancies · 01a10f0d
      Philippe Gerum authored
      Post ABI 18 libevl would fail to detect incompatible core support by
      receiving ENOTTY as a result of asking for the core information, due
      to the change in size of the argument struct which was introduced to
      support ABI ranges. Make sure to trap ENOTTY on this call as an ABI
      mismatch too.
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
    • Philippe Gerum's avatar
      include: do not export uapi/linux · a9653c72
      Philippe Gerum authored
      uapi/evl should not directly depend on uapi/linux from the same kernel
      release. The kernel definitions we need in uapi/evl should be limited
      to linux/types.h, as available from a current toolchain. Revert the
      uapi/linux export introduced by commit #5f68658b8.
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
    • Philippe Gerum's avatar
      lib: y2038: convert to timespec64 kernel interface · 4204f25b
      Philippe Gerum authored
      This set of changes makes libevl y2038-safe by switching to the ABI
      revision 19 of the EVL core, which generalizes the use of a 64bit
      timespec type. These changes also go a long way preparing for the
      upcoming mixed 32/64 ABI support (aka compat mode).
      The changes only affect the internal interface between libevl and the
      kernel, not the API.  Nevertheless, the API was bumped to revision 10
      with the removal of the evl_adjust_clock() service, which neither had
      proper specification nor defined use case currently, but would stand
      in the way of the sanitization work for y2038. At any rate, any future
      service implementing some sort of EVL clock adjustment should
      definitely not depend on the legacy struct timex which is
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
    • Philippe Gerum's avatar
    • Philippe Gerum's avatar
      utils/trace: fix argument parsing · f7c6c229
      Philippe Gerum authored
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
    • Philippe Gerum's avatar
      lib/init: state ABI requirement explicitly · 1565744d
      Philippe Gerum authored
      Instead of matching whatever ABI we might be compiled against like
      previously, define the kernel ABI we need as a prerequisite
      (EVL_KABI_PREREQ), checking for sanity at build time and runtime.
      This prerequisite is matched against the range of ABI revisions the
      kernel supports (from EVL_ABI_BASE to EVL_ABI_CURRENT). In the
      simplest case, the kernel implements a single ABI with no backward
      compatibility mechanism (EVL_ABI_BASE == EVL_ABI_CURRENT).
      This addresses two issues:
      - the fact that libevl might build against a given set of uapi/ files
        does not actually mean that the corresponding kernel ABI found there
        is fully compatible with what libevl expects. Specifying a
        compatible ABI prereq explicitly addresses this problem.
      - we can obtain services from EVL cores supporting multiple ABI
        revisions (i.e. providing backward compat feat).
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
  2. 26 Feb, 2020 1 commit
  3. 23 Feb, 2020 1 commit
  4. 21 Feb, 2020 3 commits
  5. 16 Feb, 2020 2 commits
    • Philippe Gerum's avatar
      lib/init: drop obsolete SIGEVL_ACTION_HOME · fa90a19e
      Philippe Gerum authored
      Since EVL-ABI rev. 17, the core sends an INBAND_TASK_RETUSER event to
      force a user thread to call back, so that it can switch it to
      out-of-band context. This mechanism does not require any support from
      libevl. Drop SIGEVL_ACTION_HOME since it is now useless.
    • Philippe Gerum's avatar
      build: do not default to -fasynchronous-unwind-tables · 5b33e0eb
      Philippe Gerum authored
      Crashes related to enabling precise unwind tables have been observed
      in the implementation of the arm* unwinder upon receipt of SIGCANCEL,
      triggered by a call to pthread_cancel(). Typically, the latmus program
      might randomly crash or enter a runaway loop at exit on cancelling the
      timer responder thread for no obvious reason, including anything
      related to stack sanity (size or corruption).
      This switch was originally turned on to help backtrace() in collecting
      more accurate information when called from a SIGDEBUG
      handler. Unfortunately, support for stack unwinding is tricky in
      essence, and may be broken in specific toolchain releases, causing
      segmentation violation on exit, e.g.:
      With libevl built using
      warming up on CPU0 (not isolated)...
      RTT|  00:00:01  (user, 1000 us period, priority 90, CPU0-noisol)
      RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
      RTD|      6.333|      6.874|     13.000|       0|     0|      6.333|     13.000
      RTD|      6.333|      6.904|     19.666|       0|     0|      6.333|     19.666
      RTS|      6.333|      6.889|     19.666|       0|     0|    00:00:02/00:00:02
      Segmentation fault (core dumped)
      (gdb) bt
          at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/config/arm/unwind-arm.c:240
          at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/config/arm/pr-support.c:179
          ucbp=0xb6e372a8, context=0xb6e36080, id=0)
          at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/unwind-arm-common.inc:842
          entry_vrs=<optimized out>, resuming=0)
          at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/unwind-arm-common.inc:349
          at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/config/arm/libunwind.S:359
      ---Type <return> to continue, or q <return> to quit---
          ctx=<optimized out>) at nptl-init.c:216
         from /lib/libc.so.6
      Which in this particular case pointed at:
      (gdb) x/20i $pc
      => 0xb6f4ca2c <_Unwind_VRS_Pop+244>:	ldr	r1, [r4, #0]
         0xb6f4ca2e <_Unwind_VRS_Pop+246>:	adds	r4, #4
         0xb6f4ca30 <_Unwind_VRS_Pop+248>:	str.w	r1, [r0, #-4]
         0xb6f4ca34 <_Unwind_VRS_Pop+252>:	cmp	r3, #16
         0xb6f4ca36 <_Unwind_VRS_Pop+254>:
      (gdb) info reg
      r0             0xb6e36098	3068354712
      r1             0x10	16
      r2             0x40f0	16624
      r3             0x5	5
      r4             0xf009e	983198
      r5             0xb6e36080	3068354688
      r6             0x1	1
      r7             0x40f0	16624
      r8             0x0	0
      r9             0xb6e35e24	3068354084
      r10            0x0	0
      r11            0x1	1
      r12            0xb6f5e0ac	3069567148
      sp             0xb6e35cf0	0xb6e35cf0
      lr             0xb6f4cf23	-1225470173
      pc             0xb6f4ca2c	0xb6f4ca2c <_Unwind_VRS_Pop+244>
      cpsr           0x40d1c30	67968048
      Something definitely bad happened in the unwinder. Disable this option
      by default, which works around the toolchain issue for the most common
      use case.
  6. 14 Feb, 2020 4 commits
  7. 10 Feb, 2020 9 commits
  8. 26 Jan, 2020 1 commit
  9. 25 Jan, 2020 1 commit
  10. 22 Jan, 2020 2 commits
  11. 21 Jan, 2020 2 commits
    • Philippe Gerum's avatar
      lib: rename evl_udelay() to evl_usleep() · db712cc1
      Philippe Gerum authored
      evl_udelay() was an annoying misnomer for people with kernel
      development background, as this relates to a busy wait loop, not to a
      sleeping call, which evl_udelay() actually was.
      Rename this call to evl_usleep(), converging to the glibc signature
      for usleep(3) in the same move.
    • Philippe Gerum's avatar
      tests: add status about missing kernel support · d816bdc9
      Philippe Gerum authored
      Some tests might fail due to a lack of kernel support, such as a
      missing driver which have to to be involved for running such
      tests. Introduce the EXIT_NO_SUPPORT code for this case, to be
      distinguished by the test runner from a functional failure.
  12. 20 Jan, 2020 2 commits
  13. 19 Jan, 2020 1 commit
  14. 09 Jan, 2020 3 commits
  15. 08 Jan, 2020 1 commit