[libc-dev] Q&A and the round table highlights from the virtual dev meeting

[Siva Chandra via libc-dev]

+cc gchatelet for #3 under Q&A

Hello all,

Some of the participants at the dev meeting who missed the talk and
wanted to see the answers to the questions that were asked. So, I
compiled the questions and their answers below. I noticed that some
questions came in after the Q&A concluded so I have also included
answers for them as well.

Also included in the email is a short write up of the highlights of
the round table discussion.

========
Q & A
========
1. Given there are already several c libraries, how do we plan to
increase the adoption of libc?
A. There are several libcs because each of them tries to fill in a gap
which others are not. LLVM libc was also started to fill in certain
gaps left by other popular libcs. I expect that users, who care about
the principles upon which LLVM libc is being developed, will naturally
gravitate towards LLVM libc.

2. I am curious about comparison/migration scenarios from: GNU libc; musl.
A. At a high level, it is tempting to say there shouldn't be any
difference. But, the proof is always in the pudding; Coincidentally,
we are kicking off two efforts internally at Google. One of them is
about migrating to LLVM libc from glibc, and the other is about
migrating to LLVM libc from musl. So, if there are learnings which
would benefit the externa/wider community, we will definitely share
them.

3. What codebase did you analyze for your statistics on uses of memcpy, etc.?
A. As far as I know, it was done over Google internal code bases. I
copied this mail to Guillaume who did this actual work. So, he might
be able to throw more light on this.

4. What is the timeline you believe until at least one operating
system is fully supported?
A. I am not sure how we can define "Fully supported". But, I think a
more practical thing would be to see how some of the large
applications like clang do when they are built against LLVM libc. That
is, how many symbols from the system libc will they need. Overtime we
want that to go down. I would think, realistically, we are 2 years
away from, say, getting clang to build fully against LLVM libc.

5. You mentioned your approach is to optimize the compiler rather than
hand optimize the code. What do you think that process will look like?
A. We didn't go through this exercise yet so my answer is going to be
speculative. The way I see it, we will implement something in C++ and
put it out in the real world to see how it does. If there are
performance related problems, and if we think they can be addressed by
"fixing" the compiler, then we will bring it up with the compiler
optimization folks and take it from there.

7. How modular will llvm-libc be? For example you probably wouldn't
want to mix one libc's malloc() with another's free().
A. Yes, in some cases one will have to pick groups of related
functions instead of a single function.

8. Will LLVM Libc include Posix APIs that aren't part of the C standard?
A. Yes, LLVM libc already has few POSIX APIs like mmap and munmap.

9. Will the PIE loader come to Windows as well (some day)? Will it use
PE/COFF then?
A. Yes. If it is relevant and makes sense on Windows, it will come to
Windows. If it has to be PE/COFF, then it will be PE/COFF.

10. Are there plans to add performance benchmarking for libc?
A. Yes. We already have benchmarking infrastructure for memory
functions like memcpy, bzero and memset. Going forward, we plan to
extend it to more functions.

11. Would the redirector work in a baremetal environment?
A. The redirector will work and is meaningful when the system libc is
linked in dynamically. So, if that is the case for your baremetal
environment, then redirectors should work there as well.

12. Are there any requirements about code coverage levels that tests
must achieve?
A. That's a good point and it is something we have not focused on yet.
It is probably time to do it so stay tuned to more information on
this.

13. Can the Libc be used (when it's ready) as a replacement for glibc
for cross-compilation toolchains to make those "GNU free"?
A. I do not know what exactly would "GNU free" mean. But, the goal is
obviously to build the libc out enough that it should be possible to
use it as a drop in replacement for other popular libcs.

14. Are alternate source implementations (either chosen at libc build
time or runtime) for libc routines included in the planned modularity?
A. We currently support choosing alternate implementations at build
time. In future, we will also support ifuncs.

15. Do you maintain a list of already implemented and missing features
that could be turned into a libc status page?
A. We don't and it is probably time to start doing it. Stay tuned for
more information on this.

=====================
Minutes of the round table
=====================
1. Tracking progress of LLVM libc development: One straightforward way
that was suggested was to look at all the symbols exported by say
glibc and track how many of them can LLVM libc provide at any given
point in time. It was suggested that a more practical approach might
be to track how many symbols from glibc (or the system libc) an
application like clang will need when linked against LLVM libc. Over
time, we want to see the number of symbols from glibc going down. A
member pointed out that clang might not be a very good example so we
might have to pick another interesting example.

2. LLVM libc on platforms where libc is shipped as part of the OS,
like BSD: Ed Maste pointed out a patch which tries to split FreeBSB
libc into a libc and a libsys: https://reviews.freebsd.org/D14609.
This opens the possibility of using LLVM libc, or atleast parts of it,
on FreeBSD.

3. Modular packaging and shipping of LLVM libc: This is more about
users who want to pull out a cutset of sources form LLVM libc and
include them in their third_party directories. It was pointed out that
LLVM libc's build rules can be enhanced so that building an
appropriate target can package and produce a set of sources which one
can just drop in to their third_party directory.

Thanks,
Siva Chandra