[libc-dev] Summary of the roundtable discussion at the US LLVM Dev Meeting 2019

Siva Chandra via libc-dev libc-dev at lists.llvm.org
Mon Oct 28 14:18:32 PDT 2019


Hello all,

It was encouraging to see positive support for LLVM libc during the
round table discussion. For the benefit of those were not present,
below is a high level summary of what was discussed. I encourage
others to add items I missed here.

1. Many expressed a desire to use LLVM libc in sandboxed environments.
This requires that LLVM libc provide the ability to selectively pick
and choose pieces suitable for one's context.
Side Note: This is in line with our goal of building a modular libc.
Header generation etc are part of the solution to build a modular
libc.

2. Some of the members pointed out that LLVM libc should be
implemented in a modern language so that modern static analysis tools
and sanitizers can be used to test them.
Side Note: We have started the implementation in C++. So, I guess we
are already good with respect to this point.

3. Some of the members were curious about how we build the abstraction
layer above the OS-specific syscall layer. This did not lead to a
discussion about any particular way. It was more a discussion about
making a case for the need for an abstraction layer to accommodate the
differences across OSes.
Side Note: I agree that this will be interesting. I am of the opinion
that there cannot be one single solution libc-wide. That is, how we
build the abstraction layers has to be taken up on a case-by-case
basis.

4. It was also suggested to check whether we can write parts of the
libc++ implementations in a way that they can be used by LLVM libc as
well. The implementation of std::vector was pointed out as an example
where such a scheme can be attempted.

5. With respect to header generation, there were questions about
selectively including/excluding specific standards.
Side Note: My personal opinion is that there will be aspects like this
for which we will end up using a hybrid (macros + header generation)
solution.

Thank you,
Siva Chandra


More information about the libc-dev mailing list