[PATCH] D28791: [compiler-rt][crt] Simple crtbegin and crtend implementation

Mon Dec 31 16:14:46 PST 2018

phosek added a comment.

In D28791#1343013 <https://reviews.llvm.org/D28791#1343013>, @krytarowski wrote:

> Is there intention to support Clang/LLVM by GLIBC/GNU developers? Unlikely (knowing FSF track of reactions against LLVM projects). There are no gcc/libgcc licensing concerns for software hosted on GLIBC (LGPLv3) with libgcc. There already does exist a functional implementation for this OS. There is no need to treat it as an issue on the Clang/LLVM side (maybe except ambitions).
>
> In my humble opinion we shall not expand the 'vendor lock' approach of libgcc/GNU to other platforms.
>
> There are other BSD-licensed implementations and Fuchsia can borrow the code freely.
>
> @joerg mentioned technical issues. I would add this kind of software is implemented in rather highly OS-specific and ideally compiler-independent. In my opinion it belongs to libc.

I think there's a lot of confusion around this change since the discussion has been dragging for so many months, and some of it has been only carried only on the mailing list and not on Phabricator, so I'll try to summarize the state.

We don't need `crtbegin.o`/`crtend.o` on Fuchsia. Since we're building a new OS from scratch, we have a luxury of changing the design of various aspects of our system as needed and after the initial discussion on this change, we've changed the design of Fuchsia to avoid the need for `crtbegin.o`/`crtend.o` altogether.

However, we don't have the same luxury when it comes to Linux. None of the popular Linux libc implementations (I looked at glibc, musl, newlib, uclibc and dietlibc) provide `crtbegin.o`/`crtend.o` aside from Bionic. This is how `crtbegin.o`/`crtend.o` is handled on Linux. You may disagree with it, but I don't think this is the place to argue about that design. If we could go back in time, we could argue for a different design, but that's simply not feasible. There are already vendors that build Linux, including glibc, with Clang. We're currently building an entire Linux system using Clang but we still need to pull in libgcc for `crtbegin.o`/`crtend.o`, so this isn't an ambition, it's the last remaining blocker.

My goal is to ensure that Clang supports Linux without relying on libgcc as it does today, but I'm not trying to replace `crtbegin.o`/`crtend.o` on other systems. If you look at `compiler-rt/cmake/config-ix.cmake` in this patch, it's restricted only to Linux. This is definitely not the only OS-specific bit in compiler-rt, there are other runtimes that are only supported on a single platform.

AFAIK @joerg's comments regarding technical issues were referring to the initial version of my patch which was very limited and doesn't reflect current version. I believe that the current version should address his comments and I've asked multiple times for additional feedback in case it doesn't, but I never got any. If there are other technical issues you or anyone else is aware of, please let me know and I'd be happy to address them.

Repository:
  rCRT Compiler Runtime

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D28791/new/

https://reviews.llvm.org/D28791