Link issue with libdune

[eliaskousk]

Hi, I'm working on porting Dune for AMD-V/RVI and I'm having trouble building Dune (unmodified master) on newer Linux kernels. It works fine on (k)Ubuntu 16.04 LTS with kernel 4.4 but it doesn't on the latest (k)Ubuntu 17.04 with kernel 4.10. libdune and the kernel module were built without errors but when trying to link libdune with the test programs I get relocation errors on libdune/dune.o and libdune/entry.o

$ sudo make      
make -C kern
make[1]: Entering directory '/home/Storage/SSD/Development/Software/eliaskousk/dune/kern'
mkdir -p /home/Storage/SSD/Development/Software/eliaskousk/dune/kern/tmp/.tmp_versions
make -C /lib/modules/4.10.0-32-generic/build M=/home/Storage/SSD/Development/Software/eliaskousk/dune/kern MODVERDIR=/home/Storage/SSD/Development/Software/eliaskousk/dune/kern/tmp/.tmp_versions modules
make[2]: Entering directory '/usr/src/linux-headers-4.10.0-32-generic'
  CC [M]  /home/Storage/SSD/Development/Software/eliaskousk/dune/kern/core.o
  CC [M]  /home/Storage/SSD/Development/Software/eliaskousk/dune/kern/vmx.o
  CC [M]  /home/Storage/SSD/Development/Software/eliaskousk/dune/kern/ept.o
  CC [M]  /home/Storage/SSD/Development/Software/eliaskousk/dune/kern/preempttrap.o
  LD [M]  /home/Storage/SSD/Development/Software/eliaskousk/dune/kern/dune.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /home/Storage/SSD/Development/Software/eliaskousk/dune/kern/dune.mod.o
  LD [M]  /home/Storage/SSD/Development/Software/eliaskousk/dune/kern/dune.ko
make[2]: Leaving directory '/usr/src/linux-headers-4.10.0-32-generic'
make[1]: Leaving directory '/home/Storage/SSD/Development/Software/eliaskousk/dune/kern'
make -C libdune
make[1]: Entering directory '/home/Storage/SSD/Development/Software/eliaskousk/dune/libdune'
gcc -Wall -g -O3 -MD  -o entry.o -c entry.c
gcc    -c -o dune.o dune.S
gcc    -c -o vsyscall.o vsyscall.S
gcc -Wall -g -O3 -MD  -o elf.o -c elf.c
gcc -Wall -g -O3 -MD  -o vm.o -c vm.c
gcc -Wall -g -O3 -MD  -o util.o -c util.c
gcc -Wall -g -O3 -MD  -o page.o -c page.c
gcc -Wall -g -O3 -MD  -o procmap.o -c procmap.c
gcc -Wall -g -O3 -MD  -o debug.o -c debug.c
gcc -Wall -g -O3 -MD -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -msoft-float -o trap.o -c trap.c
ar crD libdune.a entry.o dune.o vsyscall.o elf.o vm.o util.o page.o procmap.o debug.o trap.o
make[1]: Leaving directory '/home/Storage/SSD/Development/Software/eliaskousk/dune/libdune'
$ cd test
gcc -Wall -g -MD -O2 -I ../   -c -o hello.o hello.c
gcc -Wall -g -MD -O2 -I ../ hello.o -o hello -L ../libdune -ldune -lpthread
/usr/bin/ld: ../libdune/libdune.a(entry.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: ../libdune/libdune.a(dune.o): relocation R_X86_64_32S against symbol `dune_syscall_handler' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Makefile:7: recipe for target 'hello' failed
make: *** [hello] Error 1

Of-course I tried adding -fPIC on libdune's makefile but nothing changed. Since everything works fine (building and running tests/apps/benches) with 4.4 kernels I don't believe it's an actual relocation problem of the library. Maybe it's another entirely different issue, possibly known by you, i.e an incompatibility with recent kernel versions. It would be great if you can shed some light on this.

Thank you in advance, Elias

[eliaskousk]

Although irrelevant to the issue above, I forgot to mention that in order for the kernel module to compile in 4.10 I had to replace VMX_EPT_EXTENT_INDIVIDUAL_ADDR with VMX_EPT_EXTENT_INDIVIDUAL_BIT since the former is removed in 4.10+ kernel versions. Is this a correct modification?

[kkaffes]

Please see #4

We have decided not to support non-LTS versions. However, I would be happy to review any fix that addresses this issue.

[eliaskousk]

Ok thanks for the quick response. I will continue development of the AMD-V port with 16.04 and when (or if!) this is finished I will try to address newer kernel version issues and submit a PR.

[rodrigosiqueira]

@kkaffes I believe the PR #16 and #15 solve the problems reported in this issue.