[llvm-dev] A libc in LLVM
mayuyu.io via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 27 10:49:31 PDT 2019
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
> 在 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
More information about the llvm-dev