Add ELFObjectFileBase::getLoongArchFeatures, and return the proper ELF
relative reloc type for LoongArch.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Object/ELF.cpp | ||
---|---|---|
226–227 | Seems this can be tested in llvm/unittests/Object/ELFObjectFileTest.cpp: // ELF relative relocation type test. TEST(ELFObjectFileTest, RelativeRelocationTypeTest) { EXPECT_EQ(ELF::R_CKCORE_RELATIVE, getELFRelativeRelocationType(ELF::EM_CSKY)); } or in llvm/unittests/Object/ELFTest.cpp: TEST(ELFTest, getELFRelativeRelocationType) { EXPECT_EQ(ELF::R_VE_RELATIVE, getELFRelativeRelocationType(EM_VE)); } | |
llvm/lib/Object/ELFObjectFile.cpp | ||
345 | Maybe similar tests could be added like RISCV in D42629. |
Remove llvm-objdump's now unnecessary --mattr arguments in LoongArch
MC tests' RUN lines, like what D42629 did and @SixWeining suggested.
LGTM.
llvm/lib/Object/ELFObjectFile.cpp | ||
---|---|---|
354 | It's only two features so don't bother with [[fallthrough]] at present. this comment is unnecessary. |
Rebase and shorten code to avoid explanatory comment on why duplicating one line of code.
llvm/lib/Object/ELFObjectFile.cpp | ||
---|---|---|
354 | The comment was there explaining why code was duplicated instead of the shorter and arguably equally easy-to-understand approach. If it is removed but the duplicated AddFeature remained, then different people's coding style preferences could clash and I wanted to avoid such unnecessary debates. Since you asked, I've thus removed the comment and chose to [[fallthrough]] instead. It's only one line after all, and I believe even programmers so used to functional style code must retain some control-flow deciphering skills to navigate in large C++ codebase in the first place... |
Seems this can be tested in llvm/unittests/Object/ELFObjectFileTest.cpp:
or in llvm/unittests/Object/ELFTest.cpp: