MaskRay added a comment. In D128612#3618167 <https://reviews.llvm.org/D128612#3618167>, @gbenyei wrote:
> In D128612#3617955 <https://reviews.llvm.org/D128612#3617955>, @MaskRay wrote: > >> lld/ELF change should be dropped from this change. Don't use >> `config->endianness`. >> I feel sad that for little-endian users who don't use big-endian, every >> write now is slightly slower due to a check ;-) > > Hi, I'm not sure I get it. How will we have a fully functional toolchain, if > I don't implement the lld/ELF part? > In LLVM, unlike in GCC, target related decisions happen in runtime. I think > it's a high level design decision. While I can understand the pain of LE > developers getting a slightly slower linker due to endianness checking, I > sure will feel the pain of a BE developer not having a linker... > > Please explain why I shouldn't use `config->endianness`? See PPC64.cpp. See D96188 <https://reviews.llvm.org/D96188> how I added aarch64_be support. A set of representative tests should be picked with be tests. If llvm-project consensus is that we will add big-endian support, I can handle lld/ELF part. I am mostly concerned with this scenarios that some RISC-V folks click LGTM, and the change lands with no test in some areas. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D128612/new/ https://reviews.llvm.org/D128612 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
