[llvm-nm] Print 'I' for import table data in COFF
authorMartin Storsjo <martin@martin.st>
Fri, 3 Nov 2017 07:18:14 +0000 (07:18 +0000)
committerMartin Storsjo <martin@martin.st>
Fri, 3 Nov 2017 07:18:14 +0000 (07:18 +0000)
The character gets uppercased into 'I' when it's a global symbol.

In GNU binutils, nm prints 'I' for symbols classified by
bfd_is_ind_section - which probably isn't exactly/only import
tables.

When building for win32, (some incarnations of?) libtool has got
rules that try to inspect linked libraries, and in order to
be sure that it is linking to a DLL import library as opposed to
a static library, it expects to find the string " I " in the output
of $NM when run on such an import library.

GNU binutils nm also flags all of the .idata$X chunks as 'i' (while
this patch only makes it set on .idata$2 and .idata$6) and also
flags __imp__function as 'I'.

Differential Revision: https://reviews.llvm.org/D39540

llvm-svn: 317300

llvm/test/tools/llvm-nm/X86/importlibrary.test
llvm/tools/llvm-nm/llvm-nm.cpp

index 9111694..107628d 100644 (file)
@@ -1,5 +1,7 @@
 # RUN: llvm-nm -B %S/Inputs/example.lib | FileCheck --match-full-lines %s
 
+CHECK: 00000000 I __IMPORT_DESCRIPTOR_example
+CHECK: 00000000 I __NULL_IMPORT_DESCRIPTOR
 CHECK: 00000000 R __imp__constant
 CHECK: 00000000 R _constant
 CHECK: 00000000 D __imp__data
index 4ad0d95..1b093f5 100644 (file)
@@ -946,6 +946,10 @@ static char getSymbolNMTypeChar(COFFObjectFile &Obj, symbol_iterator I) {
     section_iterator SecI = *SecIOrErr;
     const coff_section *Section = Obj.getCOFFSection(*SecI);
     Characteristics = Section->Characteristics;
+    StringRef SectionName;
+    Obj.getSectionName(Section, SectionName);
+    if (SectionName.startswith(".idata"))
+      return 'i';
   }
 
   switch (Symb.getSectionNumber()) {