[PATCH] D23621: llvm-objdump: ELF: Handle code and data mix in all scenarios
khemant@codeaurora.org via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 18 09:23:17 PDT 2016
khemant added inline comments.
================
Comment at: test/tools/llvm-objdump/X86/disassemble-code-data-mix.test:15
@@ +14,3 @@
+ .globl bar
+ .type bar, at object
+bar:
----------------
compnerd wrote:
> Please uniformly choose a style (space or no space between the comma and type specifier).
Good catch, will fix this.
================
Comment at: test/tools/llvm-objdump/X86/disassemble-code-data-mix.test:18
@@ +17,3 @@
+ .string "test string"
+ .size bar, .-bar
+// CHECK: b: 74 65 73 74 20 73 74 72 test str
----------------
compnerd wrote:
> Are the sizes really needed?
In case of X86 test not really. In case of ARM test (I will upload it with some changes you recommend) it is needed so objdump can figure out that the data is "inside" a function or just a standalone data symbol in a text section.
================
Comment at: tools/llvm-objdump/llvm-objdump.cpp:1105
@@ +1104,3 @@
+ // data.
+ // This is used to pretty print the symbols while disassembling.
+ typedef std::vector<std::tuple<uint64_t, StringRef, SymbolRef::Type>>
----------------
compnerd wrote:
> Join this and the previous line?
Yes.
================
Comment at: tools/llvm-objdump/llvm-objdump.cpp:1108
@@ -1100,2 +1107,3 @@
+ SectionSymbolsTy;
std::map<SectionRef, SectionSymbolsTy> AllSymbols;
for (const SymbolRef &Symbol : Obj->symbols()) {
----------------
compnerd wrote:
> I wonder how much more expensive it is to keep a `std::vector<SymbolRef>` instead and query the Address/Name/Type from the symbol.
Good question for which I do not have any answer. The patch only made the pair into a tuple.
I see however that types, address and name all return Expected, that would mean every time we query we have to check for all of this and then decide what should be done in case of error(s).
Perhaps someone else may have an answer for this.
Repository:
rL LLVM
https://reviews.llvm.org/D23621
More information about the llvm-commits
mailing list