This is an archive of the discontinued LLVM Phabricator instance.

[NFC] Refactor the tuple of symbol information with structure for llvm-objdump
ClosedPublic

Authored by DiggerLin on Feb 7 2020, 10:19 AM.

Diff Detail

Event Timeline

DiggerLin created this revision.Feb 7 2020, 10:19 AM
DiggerLin edited reviewers, added: daltenty, Xiangling_L; removed: jhenderson.Feb 7 2020, 10:40 AM
DiggerLin removed subscribers: arsenm, jvesely, nhaehnle and 4 others.
DiggerLin retitled this revision from refactor the tuple of symbol information with structure. to refactor the tuple of symbol information with structure for llvm-objdump.Feb 7 2020, 10:49 AM
DiggerLin updated this revision to Diff 243249.Feb 7 2020, 11:23 AM
daltenty retitled this revision from refactor the tuple of symbol information with structure for llvm-objdump to [NFC] Refactor the tuple of symbol information with structure for llvm-objdump.Feb 10 2020, 6:49 AM
daltenty added inline comments.Feb 10 2020, 8:15 AM
llvm/include/llvm/MC/MCDisassembler/MCDisassembler.h
23

Can we give a more precise type for this field? It only seems to take on ELF::STT enum values.

DiggerLin marked an inline comment as done.Feb 10 2020, 10:06 AM
DiggerLin added inline comments.
llvm/include/llvm/MC/MCDisassembler/MCDisassembler.h
23

in the ELF , the Type is means symbol type(in all the info in the SymbolInfoTy should be symbol related. ) , it is only ELF object file use the data member now. We will use the Type data member to store "Store Mapping class" of symbol in next patch, it is a refactor patch , I prefer to keep the Name "Type" here, we can change the name to other in the next patch.

daltenty added inline comments.Feb 10 2020, 10:50 AM
llvm/include/llvm/MC/MCDisassembler/MCDisassembler.h
23

Sorry, to clarify I'm proposing changing the type of the Type field, not the name (it's confusing to talk about the type of a field named Type unfortunately).

Specifically I mean naming th ELF unnamed enum involved in BinaryFormat/ELF.h and specifying it here (an enum class would be nice but that may not be possible).

Something like:

struct SymbolInfoTy {
uint64_t  Addr;
StringRef Name;
Elf::STType  Type;
}

Provided the enum was named to STType. We would then introduce a union in the follow on patch.

DiggerLin marked an inline comment as done.Feb 10 2020, 12:34 PM
DiggerLin added inline comments.
llvm/include/llvm/MC/MCDisassembler/MCDisassembler.h
23

change to type Elf::STTType and I need to added a new include header file BinaryFormat/ELF.h

and the Type "Elf::STType" will be change soon to "int16_t" in later patch.

daltenty accepted this revision.Feb 10 2020, 12:36 PM

LGTM (with note about later follow on)

llvm/include/llvm/MC/MCDisassembler/MCDisassembler.h
23

Summary of offline discussion: This would probably necessitate revamping the enums in elf.h quite a bit, so this probably is best done as a latter follow on patch.

This revision is now accepted and ready to land.Feb 10 2020, 12:36 PM
This revision was automatically updated to reflect the committed changes.
jasonliu added inline comments.Feb 10 2020, 11:55 PM
llvm/include/llvm/MC/MCDisassembler/MCDisassembler.h
25

Any reason why a constructor is needed? It could be an aggregate and initialize with {}?

jasonliu added inline comments.Feb 11 2020, 12:36 AM
llvm/tools/llvm-objdump/llvm-objdump.cpp
344–352

Prefer this to be a friend function inside of struct SymbolInfoTy, as this operator could be used in other compilation unit.

Also, the function would be easier to reason about and maintain if we write it as:
{

return std::tie(P1.Addr, P1.Name, P1.Type) < std::tie(P2.Addr, P2.Name, P2.Type);

}

Xiangling_L added inline comments.Feb 11 2020, 7:25 AM
llvm/include/llvm/MC/MCDisassembler/MCDisassembler.h
12

Since you add the header of StringRef, then forward declaration of class StringRef can be removed on line 33?

llvm/tools/llvm-objdump/llvm-objdump.cpp
345

Based on Jason's comment, maybe you can further simplify the function as:

bool operator<(const SymbolInfoTy& ST) const {
          return std::tie(Addr, Name, Type) < std::tie(ST.Addr, ST.Name, ST.Type);
        }
jasonliu added inline comments.Feb 11 2020, 7:36 AM
llvm/tools/llvm-objdump/llvm-objdump.cpp
345

Re @Xiangling_L
I still think a hidden friend function is a better idea than a member function (based on the syntax you are using):
https://www.justsoftwaresolutions.co.uk/cplusplus/hidden-friends.html

jasonliu added inline comments.Feb 11 2020, 7:45 AM
llvm/tools/llvm-objdump/llvm-objdump.cpp
345

Another article talks about overloading operator function, hopefully it would help: https://www.learncpp.com/cpp-tutorial/94-overloading-operators-using-member-functions/

DiggerLin marked 3 inline comments as done.Feb 11 2020, 8:30 AM
DiggerLin added inline comments.
llvm/include/llvm/MC/MCDisassembler/MCDisassembler.h
12

good finding . I will delete is in another patch

25

yes, I think we need it in the code

Symbols.insert(
        Symbols.begin(),
         SymbolInfoTy(SectionAddr, SectionName,
                        Section.isText() ? ELF::STT_FUNC : ELF::STT_OBJECT))
llvm/tools/llvm-objdump/llvm-objdump.cpp
345
  1. If you’re overloading a binary operator that does not modify its left operand (e.g. operator+), do so as a normal function (preferred) or friend function.
  1. , before the patch, it use tuple which compare address, Name, Type, but the type always is STT_NOTYPE for xcoffobject . The type value(storage mapping class) will be change in later patch , if we compare the type , it will cause a lot of xcoff dissemble test case to change. I do not use the Type data member as compare value.
  1. the function std::tie generate a tuple, as we talk about we do not use tuple, why we use a tie ?
Xiangling_L added inline comments.Feb 11 2020, 9:04 AM
llvm/tools/llvm-objdump/llvm-objdump.cpp
345

Thank you for providing those articles, they are really helpful. And I agree that there are extra benefits comparing hidden friend function than member function in this case.

jasonliu added inline comments.Feb 11 2020, 9:21 AM
llvm/include/llvm/MC/MCDisassembler/MCDisassembler.h
25

Okk.

This line does not have proper indentation I think. If we are going to fix other issues mentioned below, I would prefer to have it fix as well.

llvm/tools/llvm-objdump/llvm-objdump.cpp
345
  1. Friend function is a normal function too. Declaring it as private inside the class will help with the lookup speed for the function. And my biggest complain is that this is a static function only available in this translation unit.
  2. You don't have to compare it if you don't want. I write the Type out because it's the original behavior. And if it's subject to change later, I'm fine with that. But for this patch, that comparison should still holds.
  3. We don't want tuple because we need to use std::get<?> everywhere. And this case, by making it a tuple only in comparison, it's easier to reason about what the order is for comparison. And easier to maintain as well, as most of time, people know they only need to add one more parameter to the tuple if they add a new data member to this structure.
jasonliu added inline comments.Feb 11 2020, 9:28 AM
llvm/tools/llvm-objdump/llvm-objdump.cpp
345
  1. You don't have to compare it if you don't want. I write the Type out because it's the original behavior. And if it's subject to change later, I'm fine with that. But for this patch, that comparison should still holds.

Also, since this is an NFC patch, we are not suppose to change any functional behavior right?

This comment was removed by leonardchan.

Actually, disregard my last comment. I think I might've made a mistake on the bisect. Sorry!