GitLab

We did produce the depfiles, but no target would depend on it. Oh,
well.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Instead of requiring all commands to be located at $libexec, simply do
a search path look up for evl-<command_name> via execvp().

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 <rpm@xenomai.org>

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 <rpm@xenomai.org>

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
y2038-unsafe.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

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 <rpm@xenomai.org>

This won't change anything EVL-wise, but this minimizes the risk of
conflicting thread priorities when running the in-band GPIO test over
a native preemption kernel.

Make sure we always drop the stax before exiting the test thread,
otherwise we might deadlock contenders. Replace the async cancellation
with a synchronous exit condition.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Calling evl_read_clock() before the library is initialized should not
fault. Set arch_clock_gettime() to a valid fallback routine which
eventually hands over the request to clock_gettime().
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

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.

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
gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf:

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
^C
---|-----------|-----------|-----------|--------|------|-------------------------
RTS|      6.333|      6.889|     19.666|       0|     0|    00:00:02/00:00:02
Segmentation fault (core dumped)

(gdb) bt
    regclass=regclass@entry=_UVRSC_CORE,
    discriminator=discriminator@entry=16624,
    representation=representation@entry=_UVRSD_UINT32)
    at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/config/arm/unwind-arm.c:240
    uws=uws@entry=0xb6e35e64)
    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.

This covers the uninit case (i.e. evl_init() did not run yet) and
whenever evl_vprint_proxy() is given an obviously invalid proxyfd
(i.e. negative), in which case we want the message to be sent out if
the caller runs in-band (not to induce any stage switch).

The in-band SCHED_BATCH and SCHED_IDLE policies should translate as
[SCHED_WEAK, 0] when attaching a thread to the core.

There is no point in receiving SIGDEBUG as a result of calling ioctl()
to detach from the core.

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.

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.

Replace -a (abort-on-switch) with -K (keep-going upon
switch). Aborting becomes the default setting upon unexpected switch
to in-band mode of the responder thread, in order to prevent any
misinterpretation of broken results obtained from a broken set up.