GCC 10 warnings on Fedora 32

Waldek Kozaczuk

unread,

May 5, 2020, 11:09:58 AM5/5/20

to OSv Development

Trying to build OSv on Fedora 32 with GCC 10 yields (unsurprisingly) errors:

" AS arch/x64/boot.S

CXX bsd/init.cc

CXX bsd/net.cc

CXX bsd/x64/machine/in_cksum.cc

CC bsd/sys/crypto/rijndael/rijndael-alg-fst.c

CC bsd/sys/crypto/rijndael/rijndael-api.c

In file included from include/osv/mutex.h:84,

from arch/x64/exceptions.hh:15,

from arch/x64/arch-cpu.hh:12,

from include/osv/sched.hh:13,

from include/osv/percpu.hh:11,

from ./bsd/porting/uma_stub.h:161,

from ./bsd/sys/sys/mbuf.h:40,

from bsd/x64/machine/in_cksum.cc:45:

/usr/include/c++/10/mutex: In member function ‘bool std::timed_mutex::_M_clocklock(clockid_t, const __gthread_time_t&)’:

/usr/include/c++/10/mutex:270:17: error: ‘pthread_mutex_clocklock’ was not declared in this scope; did you mean ‘pthread_mutex_timedlock’?

270 | { return !pthread_mutex_clocklock(&_M_mutex, clockid, &__ts); }

| ^~~~~~~~~~~~~~~~~~~~~~~

| pthread_mutex_timedlock

/usr/include/c++/10/mutex: In member function ‘bool std::recursive_timed_mutex::_M_clocklock(clockid_t, const __gthread_time_t&)’:

/usr/include/c++/10/mutex:336:17: error: ‘pthread_mutex_clocklock’ was not declared in this scope; did you mean ‘pthread_mutex_timedlock’?

336 | { return !pthread_mutex_clocklock(&_M_mutex, clockid, &__ts); }

| ^~~~~~~~~~~~~~~~~~~~~~~

| pthread_mutex_timedlock

CC bsd/sys/crypto/rijndael/rijndael-api-fst.c

In file included from include/osv/mutex.h:84,

from include/osv/debug.hh:16,

from bsd/net.cc:8:

/usr/include/c++/10/mutex: In member function ‘bool std::timed_mutex::_M_clocklock(clockid_t, const __gthread_time_t&)’:

/usr/include/c++/10/mutex:270:17: error: ‘pthread_mutex_clocklock’ was not declared in this scope; did you mean ‘pthread_mutex_timedlock’?

270 | { return !pthread_mutex_clocklock(&_M_mutex, clockid, &__ts); }

| ^~~~~~~~~~~~~~~~~~~~~~~

| pthread_mutex_timedlock

/usr/include/c++/10/mutex: In member function ‘bool std::recursive_timed_mutex::_M_clocklock(clockid_t, const __gthread_time_t&)’:

/usr/include/c++/10/mutex:336:17: error: ‘pthread_mutex_clocklock’ was not declared in this scope; did you mean ‘pthread_mutex_timedlock’?

336 | { return !pthread_mutex_clocklock(&_M_mutex, clockid, &__ts); }

| ^~~~~~~~~~~~~~~~~~~~~~~

| pthread_mutex_timedlock

In file included from include/osv/mutex.h:84,

from include/osv/debug.hh:16,

from bsd/init.cc:8:

/usr/include/c++/10/mutex: In member function ‘bool std::timed_mutex::_M_clocklock(clockid_t, const __gthread_time_t&)’:

/usr/include/c++/10/mutex:270:17: error: ‘pthread_mutex_clocklock’ was not declared in this scope; did you mean ‘pthread_mutex_timedlock’?

270 | { return !pthread_mutex_clocklock(&_M_mutex, clockid, &__ts); }

| ^~~~~~~~~~~~~~~~~~~~~~~

| pthread_mutex_timedlock

/usr/include/c++/10/mutex: In member function ‘bool std::recursive_timed_mutex::_M_clocklock(clockid_t, const __gthread_time_t&)’:

/usr/include/c++/10/mutex:336:17: error: ‘pthread_mutex_clocklock’ was not declared in this scope; did you mean ‘pthread_mutex_timedlock’?

336 | { return !pthread_mutex_clocklock(&_M_mutex, clockid, &__ts); }

| ^~~~~~~~~~~~~~~~~~~~~~~

| pthread_mutex_timedlock

CC bsd/sys/crypto/sha2/sha2.c

CC bsd/sys/libkern/arc4random.c

make: *** [Makefile:331: build/release.x64/bsd/x64/machine/in_cksum.o] Error 1

make: *** Waiting for unfinished jobs....

"

Cannot quite figure out why we are getting those and what the fix might be.

Waldek Kozaczuk

unread,

May 5, 2020, 11:10:33 AM5/5/20

to OSv Development

I wonder if that is related - https://gcc.gnu.org/legacy-ml/gcc-patches/2019-10/msg01118.html?

Nadav Har'El

unread,

May 5, 2020, 12:30:13 PM5/5/20

to Waldek Kozaczuk, OSv Development

Sorry about being unresponsive lately. Trying to correct that (a bit) with this response.

I haven't upgraded any machine to Fedora 32 yet (I'll do it soon), so I can't test this myself. But I can make a suggestion without trying it:

On Tue, May 5, 2020 at 6:09 PM Waldek Kozaczuk <jwkoz...@gmail.com> wrote:

Trying to build OSv on Fedora 32 with GCC 10 yields (unsurprisingly) errors:

" AS arch/x64/boot.S
CXX bsd/init.cc
CXX bsd/net.cc
CXX bsd/x64/machine/in_cksum.cc
CC bsd/sys/crypto/rijndael/rijndael-alg-fst.c
CC bsd/sys/crypto/rijndael/rijndael-api.c
In file included from include/osv/mutex.h:84,
from arch/x64/exceptions.hh:15,
from arch/x64/arch-cpu.hh:12,
from include/osv/sched.hh:13,
from include/osv/percpu.hh:11,
from ./bsd/porting/uma_stub.h:161,
from ./bsd/sys/sys/mbuf.h:40,
from bsd/x64/machine/in_cksum.cc:45:
/usr/include/c++/10/mutex: In member function ‘bool std::timed_mutex::_M_clocklock(clockid_t, const __gthread_time_t&)’:
/usr/include/c++/10/mutex:270:17: error: ‘pthread_mutex_clocklock’ was not declared in this scope; did you mean ‘pthread_mutex_timedlock’?
270 | { return !pthread_mutex_clocklock(&_M_mutex, clockid, &__ts); }

It appears that the new <mutex> C++ header file (included by include/osv/mutex.h, I don't remember why) needs pthread_mutex_clocklock() to be defined in our pthread header files.

Let's just implement this function. Seeing that our pthread_mutex_timedlock() is already a stub (nobody ever complained...), pthread_mutex_clocklock() can also be a stub.

I think this will be easy, and hopefully work.

Waldek Kozaczuk

unread,

May 6, 2020, 12:03:59 AM5/6/20

to OSv Development

After the new 4th patch applied OSv compiles and links with GCC 10.

But it does not quite boot properly not build ZFS images.

For example one can build ROFS image and run it with '-k' option successfully:

./scripts/build image=native-example fs=rofs -j4
./scripts/run.py -k

The same image also runs on firecracker.

The same command to build default ZFS image hangs when booting bare OSv loader like so:

./scripts/build image=native-example -j4
Building into build/release.x64
  GEN gen/include/osv/version.h
No such image configuration: native-example. Assuming list of modules.
Importing /home/wkozaczuk/projects/osv/apps/native-example/module.py
Modules:
  native-example.*
make: Nothing to be done for 'module'.
Preparing usr.manifest
Appending /home/wkozaczuk/projects/osv/apps/native-example/usr.manifest to usr.manifest
Preparing bootfs.manifest
Saving command line to /home/wkozaczuk/projects/osv/build/release.x64/cmdline
Building into build/release.x64
  GEN gen/include/osv/version.h
  MKBOOTFS build/release.x64/bootfs.bin
  AS bootfs.S
  LINK loader.elf
{standard input}: Assembler messages:
{standard input}:4094: Warning: symbol '_ZNSt7codecvtIwc11__mbsta' already has its type set
{standard input}:4556: Warning: symbol '_ZN6virtio13virtio_driver' already has its type set
{standard input}:6188: Warning: symbol '_ZN6virtio13virtio_driver' already has its type set
{standard input}:11948: Warning: symbol '_ZN9pagecache14access_sca' already has its type set
{standard input}:13928: Warning: symbol '_ZN9pagecache14access_sca' already has its type set
{standard input}:16104: Warning: symbol '_ZNSt7codecvtIDic11__mbst' already has its type set
{standard input}:19108: Warning: symbol '_ZNSt7codecvtIwc11__mbsta' already has its type set
{standard input}:20612: Warning: symbol '_ZNSt6chrono3_V212system_' already has its type set
{standard input}:20968: Warning: symbol '_ZNSt7codecvtIDsc11__mbst' already has its type set
{standard input}:21272: Warning: symbol '_ZNSt7codecvtIDiDu11__mbs' already has its type set
{standard input}:21336: Warning: symbol '_ZN9pagecache15cached_pag' already has its type set
{standard input}:21372: Warning: symbol '_ZN9__gnu_cxx17__pool_all' already has its type set
{standard input}:23464: Warning: symbol '_ZNSt6chrono3_V212steady_' already has its type set
{standard input}:23844: Warning: symbol '_ZNSt17__timepunct_cacheI' already has its type set
{standard input}:24178: Warning: symbol '_ZN9pagecache14access_sca' already has its type set
{standard input}:24758: Warning: symbol '_ZNSt7codecvtIDsDu11__mbs' already has its type set
{standard input}:27704: Warning: symbol '_ZNSt7codecvtIcc11__mbsta' already has its type set
{standard input}:28072: Warning: symbol '_ZNSt6chrono12system_cloc' already has its type set
{standard input}:28396: Warning: symbol '_ZN9pagecache14access_sca' already has its type set
{standard input}:29162: Warning: symbol '_ZN3osv3rcu26cpu_quiescen' already has its type set
{standard input}:31774: Warning: symbol '_ZN9__gnu_cxx17__pool_all' already has its type set
{standard input}:32984: Warning: symbol '_ZN9__gnu_cxx17__pool_all' already has its type set
  LIBOSV.SO
  STRIP loader.elf -> loader-stripped.elf 
  LZ loader-stripped.elf
  AS arch/x64/vmlinuz-boot32.S
  LD build/release.x64/vmlinuz-boot.bin
  DD vmlinuz.bin vmlinuz-boot.bin
  DD vmlinuz.bin loader-stripped.elf
  OBJCOPY loader-stripped.elf.lz -> loader-stripped.elf.lz.o
  LINK lzloader.elf
  ALIGN lzloader.elf
  AS arch/x64/boot16.S
  LD build/release.x64/boot.bin
  DD loader.img boot.bin
  DD loader.img lzloader.elf
  IMGEDIT build/release.x64/loader.img
  IMGEDIT build/release.x64/loader.img
...
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
KVM: injection failed, MSI lost (Operation not permitted)
....

This same happens when trying to run ROFS image without '-k' option.

This makes me thing that kernel.elf/loader.elf are functional but there is something wrong with loader.img/usr..img so the traditional (non-direct kernel boot) boot from real mode through protected fails somewhere early. I wonder if there is something wrong with lzloader.elf or boot.S that does not work with GCC 10.

Waldek

Reply all

Reply to author

Forward