[llvm-dev] A libc in LLVM

[mayuyu.io via llvm-dev]

I surely want to see this happen to. But afaik on Darwin the libc(libSystem) is even more complicated and plays an integral part of ObjectiveC/DYLD runtime. I don't think we’ll be able to achieve what we need without literally reimplementing everything

Zhang

> 在 2019年6月27日，19:16，Kamil Rytarowski via llvm-dev <llvm-dev at lists.llvm.org> 写道：
> 
>> On 25.06.2019 21:12, Rich Felker via llvm-dev wrote:
>> Since I have a little experience in this area, I'd like to chime in on
>> it. :-) TL;DR I think it's a reall, REALLY bad idea.
> 
> As a contributor to NetBSD libc, I don't see any benefits in the
> proposal. Mentioned motivations like static linking, static PIE are
> supported natively out of the box.
> 
> Tighter sanitizer integration? NetBSD supports in-libc UBSan and
> whole-distribution sanitization (ASan, UBSan, TSan, MSan.. in various
> degrees of completeness).
> 
> Licensing issues? The implementation is (L)GPL-free...
> 
> NetBSD libc is an integral and inseparable part of the NetBSD
> distribution. We share the same code with the kernel, userland
> utilities, bootloader, rumpkernels..
> 
> Every kernel has its own specific syscall ABI layer and thus parts like
> libpthread need to be implemented largely for each OS separately. Even
> every BSD is totally different here. Portable libdl? Not really as we
> shall support dynamic loader specifics on per-OS basis.
> 
> Furthermore downstream OSs like NetBSD need downstream specific behavior
> in toolchain that is tightly integrated into loader/libc/kernel.
> 
> Reimplementing libc would be a tremendous work for literally no gain.
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev