Aaron Ballman via llvm-dev <llvm-dev at lists.llvm.org> writes:>> * Ability to layer this libc over the system libc.Echoing others, this seems dubious to me. Why not build up small pieces at a time and write tests for them? This library doesn't need to support all existing programs out of the gate. I dont't think libc++ layered on top of existing standard C++ libraries, so why would libc need to?>> * Provide C symbols as specified by the standards, but take advantage >> and use C++ language facilities for the core implementation.Does this mean C programs would require a C++ runtime? If not, how will the project ensure that? -David
On Fri, Jul 12, 2019 at 9:15 AM David Greene <dag at cray.com> wrote:> > Aaron Ballman via llvm-dev <llvm-dev at lists.llvm.org> writes: > > >> * Ability to layer this libc over the system libc. > > Echoing others, this seems dubious to me. Why not build up small pieces > at a time and write tests for them? This library doesn't need to > support all existing programs out of the gate. I dont't think libc++ > layered on top of existing standard C++ libraries, so why would libc > need to?I do not think we are saying we "need to". We are only saying it "has the ability to". One can choose not to use this ability, but having this ability might be crucial for adoption for some users.> >> * Provide C symbols as specified by the standards, but take advantage > >> and use C++ language facilities for the core implementation. > > Does this mean C programs would require a C++ runtime? If not, how will > the project ensure that?This is a very good question. I think, to keep things simple and sane, llvm-libc should not require a C++ runtime. If this needs some form of relaxation later, then we can take it up on a case by case basis. About ensuring that there is no accidental dependence on a C++ runtime, at a very high level, I think suitably configured bots would suffice? There could be some tooling, but might have to be taken up on a case by case basis again.
On Fri, Jul 12, 2019 at 9:15 AM David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Aaron Ballman via llvm-dev <llvm-dev at lists.llvm.org> writes: > > >> * Ability to layer this libc over the system libc. > > Echoing others, this seems dubious to me. Why not build up small pieces > at a time and write tests for them? This library doesn't need to > support all existing programs out of the gate.I can *definitely* appreciate that not everybody wants a Frankenstein's-monster-of-a-library. For what it's worth... for our usage (within Google, and specifically, within the production fleet), it is much more imperative to show broad usage sooner rather than later. It might make more sense from this perspective: we want to develop in the open (i.e., not just throw some code over the fence when we're "done enough"); and we want it to be of high enough quality that others might use it. In order to do this, we actually need to deliver the "low-hanging fruit" first, because that is a large part of what justifies the rest. Realities being what they are, it would be a non-starter to have no such facility; and it would be somewhat antithetical to carry out such a substantial part of our development effort behind closed doors.> I dont't think libc++ > layered on top of existing standard C++ libraries, so why would libc > need to?There will almost certainly be other platforms where a top-to-bottom implementation would be impossible to implement. Not because of the libc parts, but functionality that -- for whatever reason -- is only available in a library that is also a libc. (Examples off the top of my head: sandboxed environments, platforms which only allow syscalls through a provided DSO, or platforms which embed some critical functionality within the same binary blob as a vendor-provided libc.)> >> * Provide C symbols as specified by the standards, but take advantage > >> and use C++ language facilities for the core implementation. > > Does this mean C programs would require a C++ runtime? If not, how will > the project ensure that? >Shooting from the hip: no. Turning off exceptions, RTTI, and static initializers (i.e., things which require a guard variable) is probably enough to obviate the need for the runtime. Of course, this raises platform-specific concerns. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190712/fe9161c2/attachment.html>
David Jones <dlj at google.com> writes:> >> * Provide C symbols as specified by the standards, but take advantage > >> and use C++ language facilities for the core implementation. > > Does this mean C programs would require a C++ runtime? If not, how will > the project ensure that? > > Shooting from the hip: no. Turning off exceptions, RTTI, and static > initializers (i.e., things which require a guard variable) is probably > enough to obviate the need for the runtime.What about bits of the standard library that are not header-only? My guess is that the set of those things may be platform-dependent. -David