| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[llvm-libgcc] initial commit Note: the term "libgcc" refers to the all of libgcc.a, libgcc_eh.a, and libgcc_s.so. Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the [Linux standard base][5]. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function __GI___backtrace eventually makes its way to a [hardcoded dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and libunwind have the same ABI, but different implementations, the two libraries end up [cross-talking, which ultimately results in a segfault][2]. To solve this problem, libunwind needs to build a “libgcc”. That is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as libgcc.a, libgcc_eh.a, and libgcc_s.so, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts. We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations. This problem has been solved in this manner for [FreeBSD][3], and this CL has been tested against [Chrome OS][4]. [1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16 [3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s [4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947 [5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html Differential Revision: https://reviews.llvm.org/D108416 | 4 年前 | |
[runtimes] Correctly apply libdir subdir for multilib (#93354) We weren't applying the libdir subdir to header directories but this is necessary for correctness when building e.g. ASan variant. This change also updates path construction logic accross all runtimes and ensures they're consistent. | 2 年前 | |
[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) There are some issues in llvm-libgcc before this patch: Commit c5a20b518203613497fa864867fc232648006068 ([llvm-libgcc] initial commit) uses $<TARGET_OBJECTS:unwind_static> to get libunwind objects, which is empty. The built library is actually a shared version of libclang_rt.builtins. When configuring with llvm/CMakeLists.txt, target llvm-libgcc requires a corresponding target in llvm-libgcc/CMakeLists.txt. Per target installation is not handled by llvm-libgcc, which is not consistent with libunwind. This patch fixes those issues by: Reusing target unwind_shared in libunwind, linking compiler-rt.builtins objects into it, and applying version script. Adding target llvm-libgcc, creating symlinks, and utilizing cmake's dependency and component mechanism to ensure link targets will be built and installed along with symlinks. Mimicking libunwind to handle per target installation. It is quite hard to set necessary options without further modifying the order of runtime projects in runtimes/CMakeLists.txt. So though this patch reveals the possibility of co-existence of llvm-libgcc and compiler-rt/libunwind in LLVM_ENABLE_RUNTIMES, we still inhibit it to minimize influence on other projects, considering that llvm-libgcc is only intended for toolchain vendors, and not for casual use. | 2 年前 | |
[NFC][Py Reformat] Reformat python files in the rest of the dirs This is an ongoing series of commits that are reformatting our Python code. This catches the last of the python files to reformat. Since they where so few I bunched them together. Reformatting is done with black. If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. If you run into any problems, post to discourse about it and we will try to help. RFC Thread below: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Reviewed By: jhenderson, #libc, Mordante, sivachandra Differential Revision: https://reviews.llvm.org/D150784 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 |