Currently we have 2 large printDynamicRelocations methods that
have a very similar code for GNU/LLVM styles.
This patch removes the duplication and renames them to printDynamicReloc
for consistency.
Depends on D87141
Paths
| Differential D87087
[llvm-readobj/elf] - Generalize the code for printing dynamic relocations. NFCI. ClosedPublic Authored by grimar on Sep 3 2020, 6:23 AM.
Details Summary Currently we have 2 large printDynamicRelocations methods that This patch removes the duplication and renames them to printDynamicReloc Depends on D87141
Diff Detail Event Timeline
grimar marked an inline comment as done. Comment Actions
This revision is now accepted and ready to land.Sep 7 2020, 12:37 AM Closed by commit rGdbb81881955d: [llvm-readobj/elf] - Generalize the code for printing dynamic relocations. NFCI. (authored by grimar). · Explain WhySep 7 2020, 5:37 AM This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 289888 llvm/tools/llvm-readobj/ELFDumper.cpp
|
I'm not a fan of having to go through the printRelaReloc, just to get to the printDynamicRelocation method which was being called before. I take it this is because printDynamicRelocation is templated and can't be virtual? I'm beginning to wonder if using the template solution to the Elf_Rel/Elf_Rela problem was a mistake - it's making the code harder to follow, due to there being unnecessary layers of functions (and in this case, parameters). Maybe we should use a class that can represent either an Elf_Rel or Elf_Rela, ideally with an implicit conversion constructor that is used instead of the two of them. That way, the template can be avoided, and the printDynamicRelocation could become a part of the interface. To avoid confusion, the class would not be an Elf_Rela (so that we aren't misrepresenting Elf_Rel instances internally). What do you think?