sdk-ng

sdk-ng copied to clipboard

It looks as though qemu_x86 is having some problems with SDK version 0.15.2 and c++

/home/cfriedt/zephyr-sdk-0.15.2/x86_64-zephyr-elf/bin/../lib/gcc/x86_64-zephyr-elf/12.1.0/../../../../x86_64-zephyr-elf/bin/ld.bfd: /home/cfriedt/zephyr-sdk-0.15.2/x86_64-zephyr-elf/x86_64-zephyr-elf/lib/32/soft-float/libstdc++.a(c++locale.o): in function `void std::__convert_to_v<long double>(char const*, long double&, std::_Ios_Iostate&, int* const&)':
c++locale.cc:(.text._ZSt14__convert_to_vIeEvPKcRT_RSt12_Ios_IostateRKPi+0x77): undefined reference to `__unordxf2'
/home/cfriedt/zephyr-sdk-0.15.2/x86_64-zephyr-elf/bin/../lib/gcc/x86_64-zephyr-elf/12.1.0/../../../../x86_64-zephyr-elf/bin/ld.bfd: c++locale.cc:(.text._ZSt14__convert_to_vIeEvPKcRT_RSt12_Ios_IostateRKPi+0x97): undefined reference to `__gexf2'
/home/cfriedt/zephyr-sdk-0.15.2/x86_64-zephyr-elf/bin/../lib/gcc/x86_64-zephyr-elf/12.1.0/../../../../x86_64-zephyr-elf/bin/ld.bfd: c++locale.cc:(.text._ZSt14__convert_to_vIeEvPKcRT_RSt12_Ios_IostateRKPi+0xb7): undefined reference to `__unordxf2'
/home/cfriedt/zephyr-sdk-0.15.2/x86_64-zephyr-elf/bin/../lib/gcc/x86_64-zephyr-elf/12.1.0/../../../../x86_64-zephyr-elf/bin/ld.bfd: c++locale.cc:(.text._ZSt14__convert_to_vIeEvPKcRT_RSt12_Ios_IostateRKPi+0xd7): undefined reference to `__lexf2'
/home/cfriedt/zephyr-sdk-0.15.2/x86_64-zephyr-elf/bin/../lib/gcc/x86_64-zephyr-elf/12.1.0/../../../../x86_64-zephyr-elf/bin/ld.bfd: c++locale.cc:(.text._ZSt14__convert_to_vIeEvPKcRT_RSt12_Ios_IostateRKPi+0xf4): undefined reference to `__gtxf2'

This works fine with mps2_an385, qemu_cortex_a53, qemu_riscv32, qemu_riscv64, and qemu_x86_64, so it looks as though it's localized to 32-bit x86 support. qemu_x86_64 also fails on the tls test permutation at runtime, but it's unrelated.

To reproduce with the fewest steps:

cat << EOF > submanifests/99-thrift.yaml
manifest:
  defaults:
    remote: upstream

  remotes:
    - name: upstream
      url-base: https://github.com/zephyrproject-rtos

  projects:
    - name: gsoc-2022-thrift
      path: modules/lib/thrift
      revision: main
      submodules: true
EOF
west update
twister -i -p qemu_x86 -T ../modules/lib/thrift/tests/lib/thrift/ThriftTest

^^ requires thrift to be available

brew install -y thrift
apt install -y thrift-compiler
dnf install -y thrift

cc @dcpleung

Do you have a working version of Thrift module that builds with the 0.15.2 SDK? I tried to build it and it complained about struct stat being redefined:

In file included from zephyr/include/zephyr/posix/unistd.h:10,
                 from modules/lib/thrift/.upstream/lib/cpp/src/thrift/transport/TServerSocket.cpp:58:
zephyr/include/zephyr/posix/sys/stat.h:92:8: error: redefinition of 'struct stat'
   92 | struct stat {
      |        ^~~~
In file included from zephyr-sdk-0.15.2/x86_64-zephyr-elf/x86_64-zephyr-elf/sys-include/sys/_default_fcntl.h:211,
                 from zephyr-sdk-0.15.2/x86_64-zephyr-elf/x86_64-zephyr-elf/sys-include/sys/fcntl.h:3,
                 from zephyr-sdk-0.15.2/x86_64-zephyr-elf/x86_64-zephyr-elf/sys-include/fcntl.h:1,
                 from modules/lib/thrift/.upstream/lib/cpp/src/thrift/transport/TServerSocket.cpp:55:
zephyr-sdk-0.15.2/x86_64-zephyr-elf/x86_64-zephyr-elf/sys-include/sys/stat.h:27:9: note: previous definition of 'struct stat'
   27 | struct  stat
      |         ^~~~

Do you have a working version of Thrift module that builds with the 0.15.2 SDK? I tried to build it and it complained about struct stat being redefined:

@dcpleung I've noticed the same thing. You should probably be ok if you check out a zephyr commit from last week.

Still hitting this on qemu_x86.

https://github.com/zephyrproject-rtos/gsoc-2022-thrift/pull/158 can be modified to not exclude qemu_x86 to demonstrate the issue. I suspect it will be excluded in thrift until we get a new SDK version.

this is a bigger job than it seems -- as near as I can tell, 80-bit soft float support is simply absent from glibc (and, hence, libgcc).

I haven't been able to figure out how __unordxf2 is generated. I tried using -mlong-double-64 but still got the same error.

I think right now, it might be better just to force CONFIG_FPU=y (or limit on CONFIG_CPU_HAS_FPU=y).

I haven't been able to figure out how __unordxf2 is generated. I tried using -mlong-double-64 but still got the same error.

That's the problem -- it's not generated, it should be provided in source form as a part of glibc (and copied to gcc for libgcc). But it doesn't exist, neither do any of the other *xf[23] functions necessary to support the 80-bit float format.

I think right now, it might be better just to force CONFIG_FPU=y (or limit on CONFIG_CPU_HAS_FPU=y).

I thought there were some x86 embedded targets without an FPU that Zephyr wants to support. I just tried -m32 -msoft-float -mlong-double-64 and it seemed to work for me at least, using 0.16.0-beta1 for long double operations in the application. To make this work in the math library, or other library bits, you'd have to compile those with the same options. I suspect the correct plan here is to set up the soft-float multilib build in the SDK so that it includes -mlong-double-64 vs -mlong-double-80. That seems like a perfectly reasonable plan, then we simply require Zephyr wanting soft-float to be built with -mlong-double-64, effectively re-defining the ABI for that target.

I suspect the correct plan here is to set up the soft-float multilib build in the SDK so that it includes -mlong-double-64 vs -mlong-double-80. That seems like a perfectly reasonable plan, then we simply require Zephyr wanting soft-float to be built with -mlong-double-64, effectively re-defining the ABI for that target.

That is one option; but, at that point, the x86 flavour of long double is essentially unsupported, which may or may not be a problem considering that Thrift is an RPC library (if the RPC is across the devices of different archs, this makes little sense anyway).

I wonder if we should just call this an unsupported feature and disable the long double support for Thrift by default (and make it an optional feature, that is known to be unsupported on FPU-less x86 targets)?

The lack of soft float support for 80bit Intel long double means that this type will not work anyways. However, I agree that it would be better to disable all use of long double on this platform rather than re-defining it as an alias for double -- applications expecting real 80-bit float support would not be helped by the alias.

I've disabled qemu_x86 in the Thrift PR for testing. We can punted on this and call it a day / unsupported feature on that platform. Might be worth it to add to release notes.