[Xenomai] Issues building old drivers under Xenomai 3.0.5

[Xenomai] Issues building old drivers under Xenomai 3.0.5

[Jim Langston]

Hi all,

I'm having trouble getting an old driver originally built for Xenomai 2.4
to build under Xenomai 3.0.5.  The code won't build under Ubuntu 16.04
patched with Xenomai 3.0.5 and kernel 4.9.24 and the IPipe patch for 4.9.24.

The problem seems to revolve around include pathing, and the simplest case
I can put together is as follows:

------------------
Makefile
------------------
XENOCONFIG:=/usr/xenomai/bin/xeno-config
KDIR ?= /lib/modules/`uname -r`/build
INCLUDEDIR    :=/usr/include
PWD        := $(shell pwd)
$(eval ccflags-y = -v $(shell $(XENOCONFIG) --native --rtdm --compat
--cflags))

ifneq ($(KERNELRELEASE),)
obj-m        := rfidrv2.o
else
rfidrv    : rfidrv2.c
    $(MAKE) -C $(KDIR) M=$(PWD) SUBDIRS=$(PWD) modules
endif

------------------
rfidrv2.c
------------------
#include <native/heap.h>
// Yes, just the one include line -- I removed all the rest of the code
===============================================

Output:

make -C /lib/modules/`uname -r`/build M=/home/jlangston/mi/rfidrv/rfidrv
SUBDIRS=/home/jlangston/mi/rfidrv/rfidrv modules
make[1]: Entering directory '/usr/src/linux-4.9.24'
  CC [M]  /home/jlangston/mi/rfidrv/rfidrv/rfidrv2.o
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.4'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
COLLECT_GCC_OPTIONS='-nostdinc' '-isystem'
'/usr/lib/gcc/x86_64-linux-gnu/5/include' '-I' './arch/x86/include' '-I'
'./arch/x86/include/generated/uapi' '-I' './arch/x86/include/generated'
'-I' './include' '-I' './arch/x86/include/uapi' '-I' './include/uapi' '-I'
'./include/generated/uapi' '-include' './include/linux/kconfig.h' '-D'
'__KERNEL__' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wno-trigraphs'
'-fno-strict-aliasing' '-fno-common'
'-Werror=implicit-function-declaration' '-Wno-format-security' '-std=gnu90'
'-fno-PIE' '-mno-sse' '-mno-mmx' '-mno-sse2' '-mno-3dnow' '-mno-avx' '-m64'
'-falign-jumps=1' '-falign-loops=1' '-mno-80387' '-mno-fp-ret-in-387'
'-mpreferred-stack-boundary=3' '-mskip-rax-setup' '-mtune=generic'
'-mno-red-zone' '-mcmodel=kernel' '-funit-at-a-time'
'-maccumulate-outgoing-args' '-D' 'CONFIG_X86_X32_ABI' '-D'
'CONFIG_AS_CFI=1' '-D' 'CONFIG_AS_CFI_SIGNAL_FRAME=1' '-D'
'CONFIG_AS_CFI_SECTIONS=1' '-D' 'CONFIG_AS_FXSAVEQ=1' '-D'
'CONFIG_AS_SSSE3=1' '-D' 'CONFIG_AS_CRC32=1' '-D' 'CONFIG_AS_AVX=1' '-D'
'CONFIG_AS_AVX2=1' '-D' 'CONFIG_AS_AVX512=1' '-D' 'CONFIG_AS_SHA1_NI=1'
'-D' 'CONFIG_AS_SHA256_NI=1' '-pipe' '-Wno-sign-compare'
'-fno-asynchronous-unwind-tables' '-I' 'arch/x86/xenomai/include' '-I'
'include/xenomai' '-fno-delete-null-pointer-checks' '-O2' '--param'
'allow-store-data-races=0' '-Wframe-larger-than=1024'
'-fstack-protector-strong' '-Wno-unused-but-set-variable'
'-fno-omit-frame-pointer' '-fno-optimize-sibling-calls'
'-fno-var-tracking-assignments' '-g' '-gdwarf-4' '-pg' '-mfentry' '-D'
'CC_USING_FENTRY' '-Wdeclaration-after-statement' '-Wno-pointer-sign'
'-fno-strict-overflow' '-fconserve-stack' '-Werror=implicit-int'
'-Werror=strict-prototypes' '-Werror=date-time'
'-Werror=incompatible-pointer-types' '-D' 'CC_HAVE_ASM_GOTO' '-v' '-I'
'/usr/xenomai/include/trank/posix' '-I' '/usr/xenomai/include/trank' '-D'
'__XENO_COMPAT__' '-I' '/usr/xenomai/include/cobalt' '-I'
'/usr/xenomai/include' '-D' '_GNU_SOURCE' '-D' '_REENTRANT' '-D'
'__COBALT__' '-I' '/usr/xenomai/include/alchemy' '-D' '__COBALT_WRAP__'
'-D' 'MODULE' '-D' 'KBUILD_BASENAME="rfidrv2"' '-D'
'KBUILD_MODNAME="rfidrv2"' '-c' '-o'
'/home/jlangston/mi/rfidrv/rfidrv/.tmp_rfidrv2.o' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1 -quiet -nostdinc -v -I
./arch/x86/include -I ./arch/x86/include/generated/uapi -I
./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I
./include/uapi -I ./include/generated/uapi -I arch/x86/xenomai/include -I
include/xenomai -I /usr/xenomai/include/trank/posix -I
/usr/xenomai/include/trank -I /usr/xenomai/include/cobalt -I
/usr/xenomai/include -I /usr/xenomai/include/alchemy -imultiarch
x86_64-linux-gnu -D __KERNEL__ -D CONFIG_X86_X32_ABI -D CONFIG_AS_CFI=1 -D
CONFIG_AS_CFI_SIGNAL_FRAME=1 -D CONFIG_AS_CFI_SECTIONS=1 -D
CONFIG_AS_FXSAVEQ=1 -D CONFIG_AS_SSSE3=1 -D CONFIG_AS_CRC32=1 -D
CONFIG_AS_AVX=1 -D CONFIG_AS_AVX2=1 -D CONFIG_AS_AVX512=1 -D
CONFIG_AS_SHA1_NI=1 -D CONFIG_AS_SHA256_NI=1 -D CC_USING_FENTRY -D
CC_HAVE_ASM_GOTO -D __XENO_COMPAT__ -D _GNU_SOURCE -D _REENTRANT -D
__COBALT__ -D __COBALT_WRAP__ -D MODULE -D KBUILD_BASENAME="rfidrv2" -D
KBUILD_MODNAME="rfidrv2" -isystem /usr/lib/gcc/x86_64-linux-gnu/5/include
-include ./include/linux/kconfig.h -MD
/home/jlangston/mi/rfidrv/rfidrv/.rfidrv2.o.d
/home/jlangston/mi/rfidrv/rfidrv/rfidrv2.c -quiet -dumpbase rfidrv2.c
-mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -mno-80387
-mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup
-mtune=generic -mno-red-zone -mcmodel=kernel -maccumulate-outgoing-args
-mfentry -march=x86-64 -auxbase-strip
/home/jlangston/mi/rfidrv/rfidrv/.tmp_rfidrv2.o -g -gdwarf-4 -O2 -Wall
-Wundef -Wstrict-prototypes -Wno-trigraphs
-Werror=implicit-function-declaration -Wno-format-security
-Wno-sign-compare -Wframe-larger-than=1024 -Wno-unused-but-set-variable
-Wdeclaration-after-statement -Wno-pointer-sign -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time
-Werror=incompatible-pointer-types -std=gnu90 -version -p
-fno-strict-aliasing -fno-common -fno-PIE -falign-jumps=1 -falign-loops=1
-funit-at-a-time -fno-asynchronous-unwind-tables
-fno-delete-null-pointer-checks -fstack-protector-strong
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -fno-strict-overflow -fconserve-stack --param
allow-store-data-races=0 -fstack-protector-strong -o - |
 as -v -I ./arch/x86/include -I ./arch/x86/include/generated/uapi -I
./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I
./include/uapi -I ./include/generated/uapi -I arch/x86/xenomai/include -I
include/xenomai -I /usr/xenomai/include/trank/posix -I
/usr/xenomai/include/trank -I /usr/xenomai/include/cobalt -I
/usr/xenomai/include -I /usr/xenomai/include/alchemy --64 -o
/home/jlangston/mi/rfidrv/rfidrv/.tmp_rfidrv2.o
GNU assembler version 2.26.1 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.26.1
GNU C89 (Ubuntu 5.4.0-6ubuntu1~16.04.4) version 5.4.0 20160609
(x86_64-linux-gnu)
    compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
#include "..." search starts here:
#include <...> search starts here:
 ./arch/x86/include
 ./arch/x86/include/generated/uapi
 ./arch/x86/include/generated
 ./include
 ./arch/x86/include/uapi
 ./include/uapi
 ./include/generated/uapi
 arch/x86/xenomai/include
 include/xenomai
 /usr/xenomai/include/trank/posix
 /usr/xenomai/include/trank
 /usr/xenomai/include/cobalt
 /usr/xenomai/include
 /usr/xenomai/include/alchemy
 /usr/lib/gcc/x86_64-linux-gnu/5/include
End of search list.
GNU C89 (Ubuntu 5.4.0-6ubuntu1~16.04.4) version 5.4.0 20160609
(x86_64-linux-gnu)
    compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 78b6f8b2ed219a71c67c16db887e4800
In file included from /usr/xenomai/include/alchemy/heap.h:21:0,
                 from /usr/xenomai/include/trank/native/heap.h:21,
                 from /home/jlangston/mi/rfidrv/rfidrv/rfidrv2.c:2:
/usr/lib/gcc/x86_64-linux-gnu/5/include/stdint.h:9:26: error: no include
path in which to search for stdint.h
In file included from /usr/xenomai/include/trank/posix/pthread.h:19:0,
                 from /usr/xenomai/include/copperplate/clockobj.h:22,
                 from /usr/xenomai/include/alchemy/timer.h:22,
                 from /usr/xenomai/include/alchemy/heap.h:22,
                 from /usr/xenomai/include/trank/native/heap.h:21,
                 from /home/jlangston/mi/rfidrv/rfidrv/rfidrv2.c:2:
/usr/xenomai/include/cobalt/pthread.h:19:26: fatal error: pthread.h: No
such file or directory
compilation terminated.
scripts/Makefile.build:299: recipe for target
'/home/jlangston/mi/rfidrv/rfidrv/rfidrv2.o' failed
make[2]: *** [/home/jlangston/mi/rfidrv/rfidrv/rfidrv2.o] Error 1
Makefile:1490: recipe for target '_module_/home/jlangston/mi/rfidrv/rfidrv'
failed
make[1]: *** [_module_/home/jlangston/mi/rfidrv/rfidrv] Error 2
make[1]: Leaving directory '/usr/src/linux-4.9.24'
Makefile:11: recipe for target 'rfidrv' failed
make: *** [rfidrv] Error 2

Does anyone have a driver that they could post up that uses the heap
functions, a sample 'Makefile' with different flags/include options, or any
suggestions on how to resolve the include file mess here?

Thanks,
Jim

[Xenomai] Two Minor Issues with Patches

[Stephen D. Cohen]

Dear Xenomai Team,

I have run into a couple of issues recently and have finally gotten around
to reporting them with my associated patches to correct them. These may be
of interest to others so I am posting them to the list. I am pretty sure
this is the correct way to submit them anyway.

The first issue is with debug backtrace handler and slackspot. The
backtrace handler in the kernel code is removing the virtual-memory offset
from all backtrace PCs regardless of origin. This is not appropriate for
executable files, and so addr2line (and thus slackspot) cannot report the
line numbers for these spots.

The simple solution is to check the backtrace section to see if it is from
an executable file and act accordingly. Here is the patch:

----- Start Patch -----
--- a/xenomai-3.0.5/kernel/cobalt/debug.c
+++ b/xenomai-3.0.5/kernel/cobalt/debug.c
@@ -23,6 +23,7 @@
#include <linux/mm.h>
#include <linux/signal.h>
#include <linux/vmalloc.h>
+#include <linux/elf.h>
#include <cobalt/kernel/sched.h>
#include <cobalt/kernel/heap.h>
#include <cobalt/kernel/clock.h>
@@ -246,7 +247,11 @@
if (vma == NULL)
continue;

- spot.backtrace[depth].pc = pc - vma->vm_start;
+ if (!memcmp((u8 *)vma->vm_start, ELFMAG, SELFMAG) &&
+ ((struct elfhdr *)vma->vm_start)->e_type == ET_EXEC)
+ spot.backtrace[depth].pc = pc;
+ else
+ spot.backtrace[depth].pc = pc - vma->vm_start;

/*
* Even in case we can't fetch the map name, we still
----- End Patch -----

One caveat - this issue does not appear to show up in the example on the
web page describing slackspot, and I am at a loss to explain how that can
be. Perhaps the ARM backtrace routines behave slightly differently and so
this is not an issue? I tried to investigate this on ARM but was unable to
make Xenomai on my Raspberry Pi produce ANY backtraces at all. It certainly
holds true for both 32 and 64-bit x86.

The other minor issue is the "-no-pie" problem that others have reported.
My investigation suggests that this can be resolved by simply having the
stage1 phase of wrap-link include the "-no-pie" flag. The following patch
handles that issue when necessary, without breaking PIE in general:

/\/\/\ Begin Patch /\/\/\
--- a/xenomai-3.0.5/scripts/wrap-link.sh
+++ b/xenomai-3.0.5/scripts/wrap-link.sh
@@ -203,8 +203,13 @@
done

if $stage2; then
+ if gcc --verbose 2>&1 | grep --quiet default-pie ; then
+ no_pie="-no-pie"
+ else
+ no_pie=""
+ fi
$verbose && set -x
- $dryrun $cc -o "$output.tmp" -Wl,-Ur -nostdlib $stage1_args
+ $dryrun $cc -o "$output.tmp" -Wl,-Ur $no_pie -nostdlib $stage1_args
$dryrun $cc -o "$output" "$output.tmp" $stage2_args
$dryrun rm -f $output.tmp
else
/\/\/\ End Patch /\/\/\

I hope these are helpful for others. Thanks for all the hard work on
Xenomai.

Warmest Regards,

Steve Cohen

Re: [Xenomai] Issues building old drivers under Xenomai 3.0.5

[Philippe Gerum]

On 08/30/2017 03:17 AM, Jim Langston wrote:
> Hi all,
> 
> I'm having trouble getting an old driver originally built for Xenomai 2.4
> to build under Xenomai 3.0.5.  The code won't build under Ubuntu 16.04
> patched with Xenomai 3.0.5 and kernel 4.9.24 and the IPipe patch for 4.9.24.
> 
> The problem seems to revolve around include pathing, and the simplest case
> I can put together is as follows:
> 

<snip>

> Does anyone have a driver that they could post up that uses the heap
> functions, a sample 'Makefile' with different flags/include options, or any
> suggestions on how to resolve the include file mess here?
> 

The former "native" API of Xenomai 2.x is no more available in kernel
space with Xenomai 3.x, as hosting application code there is discouraged.

With the latter, the only kernel space API is RTDM, for writing drivers.
If you need a real-time allocator in kernel space to ease your port,
there is still the option of tapping into the Cobalt core inner
interface, using the xnheap_* services.

-- 
Philippe.

Re: [Xenomai] Two Minor Issues with Patches

[Philippe Gerum]

On 08/30/2017 04:38 AM, Stephen D. Cohen wrote:
> Dear Xenomai Team,
> 
> I have run into a couple of issues recently and have finally gotten around
> to reporting them with my associated patches to correct them. These may be
> of interest to others so I am posting them to the list. I am pretty sure
> this is the correct way to submit them anyway.
> 

Queued, thanks. I'll follow up on this.

-- 
Philippe.

Re: [Xenomai] Two Minor Issues with Patches

[Philippe Gerum]

On 08/30/2017 04:38 AM, Stephen D. Cohen wrote:
> Dear Xenomai Team,
> 
> I have run into a couple of issues recently and have finally gotten around
> to reporting them with my associated patches to correct them. These may be
> of interest to others so I am posting them to the list. I am pretty sure
> this is the correct way to submit them anyway.
> 
> The first issue is with debug backtrace handler and slackspot. The
> backtrace handler in the kernel code is removing the virtual-memory offset
> from all backtrace PCs regardless of origin. This is not appropriate for
> executable files, and so addr2line (and thus slackspot) cannot report the
> line numbers for these spots.

Ack. This bug was introduced some time before Xenomai 3.0-rc1 was
released, after Linux mainline dropped the VM_EXECUTABLE flag [1], which
Cobalt used to rely upon for identifying an exec mapping.

The initial code that worked (originally on ppc32) read as:

		pc = backtrace[n];

		vma = find_vma(mm, pc);
		if (vma == NULL)
			continue;

		if (!(vma->vm_flags & VM_EXECUTABLE))
			pc -= vma->vm_start;

		spot.backtrace[depth].pc = pc;

It looks like the issue of replacing the initial check for execs was
left pending since then.

> 
> The simple solution is to check the backtrace section to see if it is from
> an executable file and act accordingly. Here is the patch:
> 
> ----- Start Patch -----
> --- a/xenomai-3.0.5/kernel/cobalt/debug.c
> +++ b/xenomai-3.0.5/kernel/cobalt/debug.c
> @@ -23,6 +23,7 @@
> #include <linux/mm.h>
> #include <linux/signal.h>
> #include <linux/vmalloc.h>
> +#include <linux/elf.h>
> #include <cobalt/kernel/sched.h>
> #include <cobalt/kernel/heap.h>
> #include <cobalt/kernel/clock.h>
> @@ -246,7 +247,11 @@
> if (vma == NULL)
> continue;
> 
> - spot.backtrace[depth].pc = pc - vma->vm_start;
> + if (!memcmp((u8 *)vma->vm_start, ELFMAG, SELFMAG) &&
> + ((struct elfhdr *)vma->vm_start)->e_type == ET_EXEC)
> + spot.backtrace[depth].pc = pc;
> + else
> + spot.backtrace[depth].pc = pc - vma->vm_start;
>

Although this would probably work with both ELF and ELF_FDPIC
(blackfin), maybe there is a better way to detect an exec mapping;
peeking at the vma contents for this purpose makes me nervous.

Maybe there is a way to relate MAP_EXECUTABLE - as passed to vm_mmap()
when called by the binfmt loaders - to the vmas, this needs to be
investigated.

> /\/\/\ Begin Patch /\/\/\
> --- a/xenomai-3.0.5/scripts/wrap-link.sh
> +++ b/xenomai-3.0.5/scripts/wrap-link.sh
> @@ -203,8 +203,13 @@
> done
> 
> if $stage2; then
> + if gcc --verbose 2>&1 | grep --quiet default-pie ; then
> + no_pie="-no-pie"
> + else
> + no_pie=""
> + fi
> $verbose && set -x
> - $dryrun $cc -o "$output.tmp" -Wl,-Ur -nostdlib $stage1_args
> + $dryrun $cc -o "$output.tmp" -Wl,-Ur $no_pie -nostdlib $stage1_args
> $dryrun $cc -o "$output" "$output.tmp" $stage2_args
> $dryrun rm -f $output.tmp
> else
> /\/\/\ End Patch /\/\/\
> 

We should move that to xeno-config*.in instead, as not everyone uses
wrap-link.sh. xeno-config would emit -no-pie, based on the detection
done in configure.ac, of a compiler enabling PIE by default.

IOW, configure.ac figures out whether $CC has default-pie, setting a
substitution variable which xeno-config*.in emits when dumping the CFLAGS.

> I hope these are helpful for others. Thanks for all the hard work on
> Xenomai.
> 

Thanks,

[1] commit e9714acf8c439688884234dcac2bfc38bb607d38
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date:   Mon Oct 8 16:28:54 2012 -0700

    mm: kill vma flag VM_EXECUTABLE and mm->num_exe_file_vmas
-- 
Philippe.

Re: [Xenomai] Two Minor Issues with Patches

[Stephen D. Cohen]

On Thu, Aug 31, 2017 at 12:13 PM Philippe Gerum <rpm@xenomai.org> wrote:


> It looks like the issue of replacing the initial check for execs was
> left pending since then.
>

     This explains why I was unable to find any way the example in the
documentation could have worked. It was simply from a version earlier than
I had imagined and I did not browse back in history quite far enough.
Though in my defense, it was part of a monolithic whole-file change-set so
rather difficult to spot. I actually find this quite a relief. I did not
like the loose-end of the working ARM example.


> Although this would probably work with both ELF and ELF_FDPIC
> (blackfin), maybe there is a better way to detect an exec mapping;
> peeking at the vma contents for this purpose makes me nervous.
>

     I completely concur on the "makes me nervous" part, but alas there is
no other way.


> Maybe there is a way to relate MAP_EXECUTABLE - as passed to vm_mmap()
> when called by the binfmt loaders - to the vmas, this needs to be
> investigated.
>

     MAP_EXECUTABLE is set for any code section, so applies to shared
libraries, PIE executables, etc. as well as executable files. The vm_mmap()
flag to follow that uniquely identifies an executable file is MAP_FIXED. I
encourage you to chase it down the vm_mmap() rabbit hole and see that there
is no corresponding flag set in the vm_flags of the vm_area_struct. At
least not that I could find. A quick perusal of the definitions for the
VM_XXX flags will show a pretty clear lack of a candidate for identifying
fixed mappings as well, to reinforce this finding.

     So with no other option, I went to the brute-force look in the ELF
header approach I submitted. This is not really as awful as it seems, given
that the sum-total of its operations is to read four bytes to make sure it
is an mapped ELF file, then read two bytes to check the type. Perhaps there
is some opportunity for vmas to be marked execute only so that the read
would cause an issue? My tracking through the ELF mapping routines suggest
this does not happen - the files are always mapped with read enabled. Plus
the code is running in the kernel so, at least in theory, has full access
regardless of the vm_flags.

     So with a lack of better options, and a sort of sour taste in my
mouth, I implemented what I submitted. I would love to be proven wrong, but
in the mean time I enjoy having slackspot actually work.

We should move that to xeno-config*.in instead, as not everyone uses
> wrap-link.sh. xeno-config would emit -no-pie, based on the detection
> done in configure.ac, of a compiler enabling PIE by default.
>

     But the issue only applies to the stage1 phase of wrap-link. There is
no fundamental issue with creating and running PIE binaries under Xenomai.
The problem is exclusive to stage1 of wrap-link passing the "-r" flag to ld.

IOW, configure.ac figures out whether $CC has default-pie, setting a
> substitution variable which xeno-config*.in emits when dumping the CFLAGS.
>

     But then you are preventing PIE binaries entirely. This may "solve"
the problem, but PIE binaries are here to stay and significantly help to
improve system security. Why force them off entirely without reason?

Warmest Regards,

Steve

Re: [Xenomai] Issues building old drivers under Xenomai 3.0.5

[Jim Langston]

Philippe,

I'm looking at the documentation for the xnheap* functions, and inserted
them into the code to replace the exising rt_heap* functions.  While it
compiles, it does not work and panics.

The offending call is the init function:

int xnheap_init ( struct xnheap *  *heap*, void *  *membase*, u32  *size*  )

>From looking at the documentation, what is the function of the "membase"
parameter, and what should I put in for its value?  Zero or NULL doesn't
work, but I have no idea what to pass to it -- is it something I get from
another function call, a fixed value, or what?

Thanks,
Jim

On Wed, Aug 30, 2017 at 3:20 AM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 08/30/2017 03:17 AM, Jim Langston wrote:
> > Hi all,
> >
> > I'm having trouble getting an old driver originally built for Xenomai 2.4
> > to build under Xenomai 3.0.5.  The code won't build under Ubuntu 16.04
> > patched with Xenomai 3.0.5 and kernel 4.9.24 and the IPipe patch for
> 4.9.24.
> >
> > The problem seems to revolve around include pathing, and the simplest
> case
> > I can put together is as follows:
> >
>
> <snip>
>
> > Does anyone have a driver that they could post up that uses the heap
> > functions, a sample 'Makefile' with different flags/include options, or
> any
> > suggestions on how to resolve the include file mess here?
> >
>
> The former "native" API of Xenomai 2.x is no more available in kernel
> space with Xenomai 3.x, as hosting application code there is discouraged.
>
> With the latter, the only kernel space API is RTDM, for writing drivers.
> If you need a real-time allocator in kernel space to ease your port,
> there is still the option of tapping into the Cobalt core inner
> interface, using the xnheap_* services.
>
> --
> Philippe.
>

Re: [Xenomai] Issues building old drivers under Xenomai 3.0.5

[Stephen D. Cohen]

Mr. Langston,

     You have to provide the memory block which conforms to the
requirements outlined in the documentation for xnheap_init. One place you
can find an example of using an xnheap is in the ipc drivers. The bind
routines in those drivers all use xnheap to manage private heaps for the
interfaces.

Regards,

Steve Cohen



On Fri, Sep 1, 2017 at 5:33 PM Jim Langston <jim.langston@gmail.com> wrote:

> Philippe,
>
> I'm looking at the documentation for the xnheap* functions, and inserted
> them into the code to replace the exising rt_heap* functions.  While it
> compiles, it does not work and panics.
>
> The offending call is the init function:
>
> int xnheap_init ( struct xnheap *  *heap*, void *  *membase*, u32  *size*
> )
>
> From looking at the documentation, what is the function of the "membase"
> parameter, and what should I put in for its value?  Zero or NULL doesn't
> work, but I have no idea what to pass to it -- is it something I get from
> another function call, a fixed value, or what?
>
> Thanks,
> Jim
>
> On Wed, Aug 30, 2017 at 3:20 AM, Philippe Gerum <rpm@xenomai.org> wrote:
>
> > On 08/30/2017 03:17 AM, Jim Langston wrote:
> > > Hi all,
> > >
> > > I'm having trouble getting an old driver originally built for Xenomai
> 2.4
> > > to build under Xenomai 3.0.5.  The code won't build under Ubuntu 16.04
> > > patched with Xenomai 3.0.5 and kernel 4.9.24 and the IPipe patch for
> > 4.9.24.
> > >
> > > The problem seems to revolve around include pathing, and the simplest
> > case
> > > I can put together is as follows:
> > >
> >
> > <snip>
> >
> > > Does anyone have a driver that they could post up that uses the heap
> > > functions, a sample 'Makefile' with different flags/include options, or
> > any
> > > suggestions on how to resolve the include file mess here?
> > >
> >
> > The former "native" API of Xenomai 2.x is no more available in kernel
> > space with Xenomai 3.x, as hosting application code there is discouraged.
> >
> > With the latter, the only kernel space API is RTDM, for writing drivers.
> > If you need a real-time allocator in kernel space to ease your port,
> > there is still the option of tapping into the Cobalt core inner
> > interface, using the xnheap_* services.
> >
> > --
> > Philippe.
> >
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>

Re: [Xenomai] Two Minor Issues with Patches

[Philippe Gerum]

On 09/01/2017 05:48 AM, Stephen D. Cohen wrote:
>      MAP_EXECUTABLE is set for any code section, so applies to shared
> libraries, PIE executables, etc. as well as executable files.

True, which means that this code never actually worked, even in its
original form... The reason it _seemed_ to work back then was because
all tests triggered relax spots from an executable, and never from DSOs:
IOW, no offset was ever subtracted from the offending $ip, which is
correct for pure executables.

 The
> vm_mmap() flag to follow that uniquely identifies an executable file is
> MAP_FIXED. I encourage you to chase it down the vm_mmap() rabbit hole
> and see that there is no corresponding flag set in the vm_flags of the
> vm_area_struct. At least not that I could find. A quick perusal of the
> definitions for the VM_XXX flags will show a pretty clear lack of a
> candidate for identifying fixed mappings as well, to reinforce this finding.
> 

I did not find any. AFAICT, load_elf_binary() sets MAP_FIXED for ET_DYN
types too, when the first loadable segment is seen by the mapping loop.

>      So with no other option, I went to the brute-force look in the ELF
> header approach I submitted. This is not really as awful as it seems,
> given that the sum-total of its operations is to read four bytes to make
> sure it is an mapped ELF file, then read two bytes to check the type.
> Perhaps there is some opportunity for vmas to be marked execute only so
> that the read would cause an issue? My tracking through the ELF mapping
> routines suggest this does not happen - the files are always mapped with
> read enabled. Plus the code is running in the kernel so, at least in
> theory, has full access regardless of the vm_flags.
> 

Ack.

>      So with a lack of better options, and a sort of sour taste in my
> mouth, I implemented what I submitted. I would love to be proven wrong,
> but in the mean time I enjoy having slackspot actually work.
> 

Ok, let's give it a day or two, so that I can squeeze in deeper review.
If no alternate option is found which does not depend on figuring out
the binary format the hard way, we'll go for your proposal.

>     We should move that to xeno-config*.in instead, as not everyone uses
>     wrap-link.sh. xeno-config would emit -no-pie, based on the detection
>     done in configure.ac <http://configure.ac>, of a compiler enabling
>     PIE by default.
> 
> 
>      But the issue only applies to the stage1 phase of wrap-link. There
> is no fundamental issue with creating and running PIE binaries under
> Xenomai. The problem is exclusive to stage1 of wrap-link passing the
> "-r" flag to ld.
> 
>     IOW, configure.ac <http://configure.ac> figures out whether $CC has
>     default-pie, setting a
>     substitution variable which xeno-config*.in emits when dumping the
>     CFLAGS.
> 
> 
>      But then you are preventing PIE binaries entirely. This may "solve"
> the problem, but PIE binaries are here to stay and significantly help to
> improve system security. Why force them off entirely without reason?
>  

The suggested approach was not aimed at forcing them off, only switching
back to the previous situation where pie was opt-in, not default. So
basically, changing xeno-config would make this opt-in again, but then
wrap-link.sh would still have a problem for people enable passing
$(xeno_config --ldflags) -pie. So, this idea was wrong and irrelevant
anyway.

Ok, fixing wrap-link.sh is the best idea. The proposed patch would break
cross-compilation though - we are not using the host's gcc compiler in
this case. We'd need to invoke $cc instead, but without the accumulated
flags, only the command path when giving --version.

-- 
Philippe.