thr3ads.net - llvm dev - [llvm-dev] Compiling libc++ using GNU Arm Embedded Toolchain for arm-cortex-m4 [Nov 2019]

If this information is useful, please help other people find it:
Share via:

Kacper Kowalski via llvm-dev

2019-Nov-13 19:33 UTC

[llvm-dev] Compiling libc++ using GNU Arm Embedded Toolchain for arm-cortex-m4

Hello,

lately, I have been thinking about how to resolve the problem with that the
program size increases enormously when including <iostream> when compiling
with libstdc++. In this library, in <iostream> there is a static object
__ioinit initialized like so:

  ...
  // For construction of filebuffers for cout, cin, cerr, clog et. al.
  static ios_base::Init __ioinit;
  ...

This makes the program size increase enormously. The thing is that I often
compile programs for small platforms, like arm-cortex-m3 or arm-cortex-m4
(stm32, nrf52, ...). Including this header leads to the program size exceed
the FLASH memory size.

This is not a problem when you have full control over what you include. But
if you use external libraries and you don't want to mess with their
sources, or you are not able to, then it gets complicated.

To resolve this issue I found out that libc++ can be compiled with the
flags:

    -D_LIBCPP_HAS_NO_STDOUT:BOOL=ON
    -D_LIBCPP_HAS_NO_STDIN:BOOL=ON

so I gave it a try: I started a struggle to compile libc++ and libc++ ABI
with ARMToolchain-9-2019-q4-major. Unfortunately, I failed.

This is how I build libc++:

TOOLCHAIN_ROOT_DIR="${HOME}/ARMToolchain-9-2019-q4-major"

export CC="${TOOLCHAIN_ROOT_DIR}/bin/arm-none-eabi-gcc"
export CXX="${TOOLCHAIN_ROOT_DIR}/bin/arm-none-eabi-g++"

C_AND_CXX_COMMON_FLAGS_BASE="-mcpu=cortex-m4 -mfpu=fpv4-sp-d16
-mfloat-abi=hard --specs=nosys.specs\
    --sysroot=${TOOLCHAIN_ROOT_DIR}
-I${TOOLCHAIN_ROOT_DIR}/arm-none-eabi/include\
    -L${TOOLCHAIN_ROOT_DIR}/lib
-L${TOOLCHAIN_ROOT_DIR}/lib/gcc/arm-none-eabi/9.2.1"
C_AND_CXX_COMMON_FLAGS_MORE="-mthumb -mabi=aapcs"
C_AND_CXX_COMMON_FLAGS="$C_AND_CXX_COMMON_FLAGS_BASE
$C_AND_CXX_COMMON_FLAGS_MORE"

cmake \
    -DCMAKE_CROSS_COMPILING:BOOL=ON \
    -DLLVM_ENABLE_PROJECTS='libcxxabi;libcxx' \
    -DCMAKE_INSTALL_PREFIX='${HOME}/ClangLibcxx' \
    -DCMAKE_BUILD_TYPE='Release' \
    -DLLVM_ENABLE_ASSERTIONS:BOOL=ON \
    -DLLVM_TARGET_ARCH='ARM' \
    -DLLVM_TARGETS_TO_BUILD='ARM' \
    -DLIBCXX_BUILD_32_BITS:BOOL=ON \
    -DLLVM_BUILD_32_BITS:BOOL=ON \
    -DLLVM_ENABLE_STATIC:BOOL=ON \
    -DLLVM_ENABLE_SHARED:BOOL=OFF \
    -DLLVM_DISABLE_PIC:BOOL=OFF \
    -D_LIBCPP_HAS_NO_STDOUT:BOOL=ON \
    -D_LIBCPP_HAS_NO_STDIN:BOOL=ON \
    -DCMAKE_C_FLAGS="$C_AND_CXX_COMMON_FLAGS" \
    -DCMAKE_CXX_FLAGS="$C_AND_CXX_COMMON_FLAGS" \
    ../llvm

Firstly, I encounter the known problem with __atomic_load_8.
arm-cortex-m{3,4} most probably doesn't support 64bit atomic read/write,
but as long as I don't use it, changing the line in CheckAtomic.cmake:

      message(FATAL_ERROR "Host compiler appears to require libatomic, but
cannot find it.")

to:

      message(WARNING "Host compiler appears to require libatomic, but
cannot find it.")

could push the things further.
But then I encounter that error:

    -- Targeting ARM
    CMake Error at
/home/kacper/Workspace/LLVMProject/libcxxabi/CMakeLists.txt:216 (message):
        LIBCXXABI_BUILD_32_BITS=ON is not supported on this platform.

which is confusing.

Can't the libc++abi be compiled for 32B ARM targets?

Best regards,
Kacper Kowalski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191113/50e98d61/attachment.html>

Peter Smith via llvm-dev

2019-Nov-14 10:18 UTC

head link

[llvm-dev] Compiling libc++ using GNU Arm Embedded Toolchain for arm-cortex-m4

On Wed, 13 Nov 2019 at 20:34, Kacper Kowalski via llvm-dev
<llvm-dev at lists.llvm.org> wrote:>
> Hello,
>
> lately, I have been thinking about how to resolve the problem with that the
program size increases enormously when including <iostream> when compiling
with libstdc++. In this library, in <iostream> there is a static object
__ioinit initialized like so:
>
>   ...
>   // For construction of filebuffers for cout, cin, cerr, clog et. al.
>   static ios_base::Init __ioinit;
>   ...
>
> This makes the program size increase enormously. The thing is that I often
compile programs for small platforms, like arm-cortex-m3 or arm-cortex-m4
(stm32, nrf52, ...). Including this header leads to the program size exceed the
FLASH memory size.
>
> This is not a problem when you have full control over what you include. But
if you use external libraries and you don't want to mess with their sources,
or you are not able to, then it gets complicated.
>
> To resolve this issue I found out that libc++ can be compiled with the
flags:
>
>     -D_LIBCPP_HAS_NO_STDOUT:BOOL=ON
>     -D_LIBCPP_HAS_NO_STDIN:BOOL=ON
>
> so I gave it a try: I started a struggle to compile libc++ and libc++ ABI
with ARMToolchain-9-2019-q4-major. Unfortunately, I failed.
>
> This is how I build libc++:
>
> TOOLCHAIN_ROOT_DIR="${HOME}/ARMToolchain-9-2019-q4-major"
>
> export CC="${TOOLCHAIN_ROOT_DIR}/bin/arm-none-eabi-gcc"
> export CXX="${TOOLCHAIN_ROOT_DIR}/bin/arm-none-eabi-g++"
>
> C_AND_CXX_COMMON_FLAGS_BASE="-mcpu=cortex-m4 -mfpu=fpv4-sp-d16
-mfloat-abi=hard --specs=nosys.specs\
>     --sysroot=${TOOLCHAIN_ROOT_DIR}
-I${TOOLCHAIN_ROOT_DIR}/arm-none-eabi/include\
>     -L${TOOLCHAIN_ROOT_DIR}/lib
-L${TOOLCHAIN_ROOT_DIR}/lib/gcc/arm-none-eabi/9.2.1"
> C_AND_CXX_COMMON_FLAGS_MORE="-mthumb -mabi=aapcs"
> C_AND_CXX_COMMON_FLAGS="$C_AND_CXX_COMMON_FLAGS_BASE
$C_AND_CXX_COMMON_FLAGS_MORE"
>
> cmake \
>     -DCMAKE_CROSS_COMPILING:BOOL=ON \
>     -DLLVM_ENABLE_PROJECTS='libcxxabi;libcxx' \
>     -DCMAKE_INSTALL_PREFIX='${HOME}/ClangLibcxx' \
>     -DCMAKE_BUILD_TYPE='Release' \
>     -DLLVM_ENABLE_ASSERTIONS:BOOL=ON \
>     -DLLVM_TARGET_ARCH='ARM' \
>     -DLLVM_TARGETS_TO_BUILD='ARM' \
>     -DLIBCXX_BUILD_32_BITS:BOOL=ON \
>     -DLLVM_BUILD_32_BITS:BOOL=ON \
>     -DLLVM_ENABLE_STATIC:BOOL=ON \
>     -DLLVM_ENABLE_SHARED:BOOL=OFF \
>     -DLLVM_DISABLE_PIC:BOOL=OFF \
>     -D_LIBCPP_HAS_NO_STDOUT:BOOL=ON \
>     -D_LIBCPP_HAS_NO_STDIN:BOOL=ON \
>     -DCMAKE_C_FLAGS="$C_AND_CXX_COMMON_FLAGS" \
>     -DCMAKE_CXX_FLAGS="$C_AND_CXX_COMMON_FLAGS" \
>     ../llvm
>
> Firstly, I encounter the known problem with __atomic_load_8.
arm-cortex-m{3,4} most probably doesn't support 64bit atomic read/write, but
as long as I don't use it, changing the line in CheckAtomic.cmake:
>
>       message(FATAL_ERROR "Host compiler appears to require libatomic,
but cannot find it.")
>
> to:
>
>       message(WARNING "Host compiler appears to require libatomic, but
cannot find it.")
>
> could push the things further.
> But then I encounter that error:
>
>     -- Targeting ARM
>     CMake Error at
/home/kacper/Workspace/LLVMProject/libcxxabi/CMakeLists.txt:216 (message):
>         LIBCXXABI_BUILD_32_BITS=ON is not supported on this platform.
>
> which is confusing.
>
> Can't the libc++abi be compiled for 32B ARM targets?
>
libc++abi can be compiled for 32-bit ARM targets. I think the intent
behind that particular option is for 64-bit X86 building for 32-bit
i386. The ARM target is only 32-bit so there isn't any need for an
option, I suggest leaving out LIBCXXABI_BUILD_32_BITS=ON,
-DLIBCXX_BUILD_32_BITS:BOOL=ON and  -DLLVM_BUILD_32_BITS:BOOL=ON

It may be worth disabling threads for libc++. From memory libc++
relies on a pthread API by default which the GNU embedded toolchain
won't supply. I think that there are ways to supply an alternative
threading implementation but I don't know the details.

Hope this helps and good luck

Peter
> Best regards,
> Kacper Kowalski
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Kacper Kowalski via llvm-dev

2019-Nov-15 18:23 UTC

head link

[llvm-dev] Compiling libc++ using GNU Arm Embedded Toolchain for arm-cortex-m4

Thank you for your answer. So I continue my struggle.

How can I disable threads for libc++? I can't find any switch in the
documentation.

Kacper

czw., 14 lis 2019 o 11:18 Peter Smith <peter.smith at linaro.org>
napisał(a):
> On Wed, 13 Nov 2019 at 20:34, Kacper Kowalski via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > Hello,
> >
> > lately, I have been thinking about how to resolve the problem with
that
> the program size increases enormously when including <iostream> when
> compiling with libstdc++. In this library, in <iostream> there is a
static
> object __ioinit initialized like so:
> >
> >   ...
> >   // For construction of filebuffers for cout, cin, cerr, clog et. al.
> >   static ios_base::Init __ioinit;
> >   ...
> >
> > This makes the program size increase enormously. The thing is that I
> often compile programs for small platforms, like arm-cortex-m3 or
> arm-cortex-m4 (stm32, nrf52, ...). Including this header leads to the
> program size exceed the FLASH memory size.
> >
> > This is not a problem when you have full control over what you
include.
> But if you use external libraries and you don't want to mess with their
> sources, or you are not able to, then it gets complicated.
> >
> > To resolve this issue I found out that libc++ can be compiled with the
> flags:
> >
> >     -D_LIBCPP_HAS_NO_STDOUT:BOOL=ON
> >     -D_LIBCPP_HAS_NO_STDIN:BOOL=ON
> >
> > so I gave it a try: I started a struggle to compile libc++ and libc++
> ABI with ARMToolchain-9-2019-q4-major. Unfortunately, I failed.
> >
> > This is how I build libc++:
> >
> > TOOLCHAIN_ROOT_DIR="${HOME}/ARMToolchain-9-2019-q4-major"
> >
> > export CC="${TOOLCHAIN_ROOT_DIR}/bin/arm-none-eabi-gcc"
> > export CXX="${TOOLCHAIN_ROOT_DIR}/bin/arm-none-eabi-g++"
> >
> > C_AND_CXX_COMMON_FLAGS_BASE="-mcpu=cortex-m4 -mfpu=fpv4-sp-d16
> -mfloat-abi=hard --specs=nosys.specs\
> >     --sysroot=${TOOLCHAIN_ROOT_DIR}
> -I${TOOLCHAIN_ROOT_DIR}/arm-none-eabi/include\
> >     -L${TOOLCHAIN_ROOT_DIR}/lib
> -L${TOOLCHAIN_ROOT_DIR}/lib/gcc/arm-none-eabi/9.2.1"
> > C_AND_CXX_COMMON_FLAGS_MORE="-mthumb -mabi=aapcs"
> > C_AND_CXX_COMMON_FLAGS="$C_AND_CXX_COMMON_FLAGS_BASE
> $C_AND_CXX_COMMON_FLAGS_MORE"
> >
> > cmake \
> >     -DCMAKE_CROSS_COMPILING:BOOL=ON \
> >     -DLLVM_ENABLE_PROJECTS='libcxxabi;libcxx' \
> >     -DCMAKE_INSTALL_PREFIX='${HOME}/ClangLibcxx' \
> >     -DCMAKE_BUILD_TYPE='Release' \
> >     -DLLVM_ENABLE_ASSERTIONS:BOOL=ON \
> >     -DLLVM_TARGET_ARCH='ARM' \
> >     -DLLVM_TARGETS_TO_BUILD='ARM' \
> >     -DLIBCXX_BUILD_32_BITS:BOOL=ON \
> >     -DLLVM_BUILD_32_BITS:BOOL=ON \
> >     -DLLVM_ENABLE_STATIC:BOOL=ON \
> >     -DLLVM_ENABLE_SHARED:BOOL=OFF \
> >     -DLLVM_DISABLE_PIC:BOOL=OFF \
> >     -D_LIBCPP_HAS_NO_STDOUT:BOOL=ON \
> >     -D_LIBCPP_HAS_NO_STDIN:BOOL=ON \
> >     -DCMAKE_C_FLAGS="$C_AND_CXX_COMMON_FLAGS" \
> >     -DCMAKE_CXX_FLAGS="$C_AND_CXX_COMMON_FLAGS" \
> >     ../llvm
> >
> > Firstly, I encounter the known problem with __atomic_load_8.
> arm-cortex-m{3,4} most probably doesn't support 64bit atomic
read/write,
> but as long as I don't use it, changing the line in CheckAtomic.cmake:
> >
> >       message(FATAL_ERROR "Host compiler appears to require
libatomic,
> but cannot find it.")
> >
> > to:
> >
> >       message(WARNING "Host compiler appears to require
libatomic, but
> cannot find it.")
> >
> > could push the things further.
> > But then I encounter that error:
> >
> >     -- Targeting ARM
> >     CMake Error at
> /home/kacper/Workspace/LLVMProject/libcxxabi/CMakeLists.txt:216 (message):
> >         LIBCXXABI_BUILD_32_BITS=ON is not supported on this platform.
> >
> > which is confusing.
> >
> > Can't the libc++abi be compiled for 32B ARM targets?
> >
>
> libc++abi can be compiled for 32-bit ARM targets. I think the intent
> behind that particular option is for 64-bit X86 building for 32-bit
> i386. The ARM target is only 32-bit so there isn't any need for an
> option, I suggest leaving out LIBCXXABI_BUILD_32_BITS=ON,
> -DLIBCXX_BUILD_32_BITS:BOOL=ON and  -DLLVM_BUILD_32_BITS:BOOL=ON
>
> It may be worth disabling threads for libc++. From memory libc++
> relies on a pthread API by default which the GNU embedded toolchain
> won't supply. I think that there are ways to supply an alternative
> threading implementation but I don't know the details.
>
> Hope this helps and good luck
>
> Peter
>
> > Best regards,
> > Kacper Kowalski
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191115/7859edb2/attachment.html>

llvm dev - Nov 2019 - Compiling libc++ using GNU Arm Embedded Toolchain for arm-cortex-m4

[llvm-dev] Compiling libc++ using GNU Arm Embedded Toolchain for arm-cortex-m4

[llvm-dev] Compiling libc++ using GNU Arm Embedded Toolchain for arm-cortex-m4

[llvm-dev] Compiling libc++ using GNU Arm Embedded Toolchain for arm-cortex-m4