[PATCH] D57105: [ELF] Return the section name when calling getSymbolName on a section symbol.

Matt Davis via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 25 08:32:58 PST 2019


mattd marked 2 inline comments as done.
mattd added a comment.

> My instinct is that the place you've made the change is too deep in the hierarchy, and that's why you have the problem in llvm-objdump. My feeling is that Symbol::getName() should probably return the name of the symbol, and leave it up to the caller to fall back and get the section name for section symbols.

Interesting point.  I was going to fix this up closer to the callsite (llvm-nm), but thought that I was fixing the wrong problem.  Therefore, I made the change deeper.  The change only uses a section name as a last resort: If there is no symbol name  or an empty symbol name.  I'm not sure we want to put the responsibility for using a section name in the caller.  Ideally, the caller (llvm-nm, etc) calls `SymbolRef::getName` and gets an Expected<StringRef>.  The caller already has to check if the current name is valid.  For a symbol representing a section, the caller would need to add more ceremony to get the SectionName, after obtaining the SectionRef and validating that the value is not an error.



================
Comment at: include/llvm/Object/ELFObjectFile.h:448
+    StringRef SecName;
+    auto Sec = getSymbolSection(Sym);
+    if (Sec && !(*Sec)->getName(SecName))
----------------
jhenderson wrote:
> I'm not sure what the type of Sec here is, so this probably shouldn't be auto (but feel free to point to a similar call in this area that uses auto, and I'll back down).
That's a  fair point.  This routine uses a variety of auto, I figured I could get away with it in this case.  I'll update this to std::error_code, which is what getSymbolSection returns.


================
Comment at: test/Object/nm-trivial-object.test:21-22
 RUN:         | FileCheck %s -check-prefix ABSOLUTE-ELF64
+RUN: llvm-nm -a %p/Inputs/IsNAN.o \
+RUN:         | FileCheck %s -check-prefix ELF64-DEBUG-SYMS
 RUN: llvm-nm %p/Inputs/trivial-object-test.macho-i386 \
----------------
jhenderson wrote:
> I'm not sure you're using the right input for this sort of test. I'd expect it to be something like `%p/Inputs/trivial-object-test.elf-x86-64`, which allows you to then compare the two sets of symbols to see what's different.
IsNAN.o has  both .debug sections and a .note section.  Testing IsNAN will exercise both of those cases in llvm-nm.cpp `getSymbolNMTypeChar.`  The test you mention (`trivial-object-test.elf-x86-64`) only has a .note section.  I wanted to test the .debug and .note cases. 


================
Comment at: test/Object/nm-trivial-object.test:123-124
+ELF64-DEBUG-SYMS: 00000000 N .debug_line
+ELF64-DEBUG-SYMS: 00000000 N .debug_pubnames
+ELF64-DEBUG-SYMS: 00000000 n .note.GNU-stack
+
----------------
jhenderson wrote:
> Aside: Why are the majority of these 'N', not 'n'? I wouldn't expect to see global section symbols... but that's my understanding of the difference between the two, based on the GNU nm man page (although I note GNU nm does the same thing).
That's the decision of `getSymbolNMTypeChar` in llvm-nm.cpp.  As you point out, the 'N' representing the names for the debug sections  is treated the same in GNU nm.  According to the GNU nm manual:
> "N" The symbol is a debugging symbol.
Since this is a section containing debug data, I assume 'N' is close enough.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57105/new/

https://reviews.llvm.org/D57105





More information about the llvm-commits mailing list