search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
28.71k stars 11.87k forks source link

Support use of libc++ with LLVM libc in embedded development #84879

Open petrhosek opened 7 months ago

petrhosek commented 7 months ago

We are trying to migrate existing baremetal projects from libstdc++ and newlib to libc++ with libc and we encountered various issues. Most of them appear to be due to the fact that unlike other C library implementations, LLVM libc does not provide a complete set of headers as defined by the C standard, rather it generates headers that only contain types and functions that are supported in baremetal environments.

For example, the baremetal version of stdio.h does not include printf, fprintf, etc. because in baremetal environments, there is typically no concept of standard output or input. This can be characterized as the "don't provide what shouldn't be used" principle.

While libc++ provides options to disable unnecessary functionality to better support restricted environments, we have still encountered cases where libc++ headers transitively pull in unnecessary dependencies. This is a high-level tracking issue, I intend to file separate issues for each case.

llvmbot commented 7 months ago

@llvm/issue-subscribers-libc

Author: Petr Hosek (petrhosek)

We are trying to migrate existing baremetal projects from libstdc++ and newlib to libc++ with libc and we encountered various issues. Most of them appear to be due to the fact that unlike other C library implementations, LLVM libc does not provide a complete set of headers as defined by the C standard, rather it generates headers that only contain types and functions that are supported in baremetal environments. For example, the [baremetal version of `stdio.h`](https://github.com/llvm/llvm-project/blob/1d900e298449d43547312364751f730b7a0d07d1/libc/config/baremetal/arm/entrypoints.txt#L73-L77) does not include `printf`, `fprintf`, etc. because in baremetal environments, there is typically no concept of standard output or input. This can be characterized as the "don't provide what shouldn't be used" principle. While libc++ provides options to disable unnecessary functionality to better support restricted environments, we have still encountered cases where libc++ headers transitively pull in unnecessary dependencies. This is a high-level tracking issue, I intend to file separate issues for each case.
philnik777 commented 7 months ago

I think there is a lot of interest in getting things working. Would it be possible to start with a CI config that builds libc++ and LLVM's libc in a freestanding configuration plus some stuff required even though it shouldn't be? Then we could work our way from that configuration to an actual freestanding one without regressing all the time.

CC @jhuber6 in case you are interested in watching any progress

frederick-vs-ja commented 7 months ago

78350 seems related.