After the N64 static relocation model support was added to llvm it is required to add its support in RuntimeDyld also because lldb uses ExecutionEngine for evaluating expressions.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp | ||
---|---|---|
874 | Shouldn't the N32ABI be reusing the O32 implementation, given it also has a 32 bit address space? | |
875–878 | This comment is out of sync with the code below. | |
883 | Shouldn't this be EF_MIPS_ARCH_64R6 ? | |
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp | ||
1319 | // Creating Highest, Higher, Hi and Lo relocations for the filled stub instructions. | |
1337–1338 | Formatting. This should be "} else {". |
Sorry for the delay in getting back to this. I've spotted something that I think is a problem. Highest & higher are processed as a pair, followed by processing Hi & Lo as a pair. I don't think this is correct, See my comment inline.
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp | ||
---|---|---|
1316–1317 | clang-format this, the indentation for the argument is incorrect. | |
1336–1340 | Indentation of the arguments and line length are wrong here. | |
1361 | Spurious whitespace after the ';'. | |
1395–1415 | I don't think this is correct for HIGHER/HIGHEST/HI/LO. You're creating two relocation entries for a symbol/section. One containing the HIGHEST+HIGHER part of the addend and the other the HI+HO. Shouldn't R_MIPS_HIGHER get pushed back as well and add the RelocationEntry after computing the addend from all four relocations? | |
lib/ExecutionEngine/RuntimeDyld/Targets/RuntimeDyldELFMips.cpp | ||
152 | Spurious blank line. |
Addressed review comments.
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp | ||
---|---|---|
1395–1415 | Actually these relocations are filled in the .rela section for n32/n64 which has a separate addend field. Do we need to do this pair matching for the calculation of the addend? |
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp | ||
---|---|---|
1361–1366 | Just realized I can use processSimpleRelocation here. I will update the diff with current TOT. |
Shouldn't the N32ABI be reusing the O32 implementation, given it also has a 32 bit address space?