This is an archive of the discontinued LLVM Phabricator instance.

[llvm-nm] Print 'I' for import table data in COFF
ClosedPublic

Authored by mstorsjo on Nov 2 2017, 2:54 AM.

Details

Summary

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 impfunction as 'I'.

Diff Detail

Repository
rL LLVM

Event Timeline

mstorsjo created this revision.Nov 2 2017, 2:54 AM
rnk accepted this revision.Nov 2 2017, 9:24 AM

lgtm

This revision is now accepted and ready to land.Nov 2 2017, 9:24 AM
smeenai edited edge metadata.Nov 2 2017, 9:32 AM

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 impfunction as 'I'.

This is just a consequence of how LLVM treats short import libraries, right? Considering that your patch returns 'i' for any .idata section, but short import libraries contain the ILT (.idata$4) and IAT (.idata$5) sections as COFFImportFile rather than COFFObjectFile.

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 impfunction as 'I'.

This is just a consequence of how LLVM treats short import libraries, right? Considering that your patch returns 'i' for any .idata section, but short import libraries contain the ILT (.idata$4) and IAT (.idata$5) sections as COFFImportFile rather than COFFObjectFile.

There's a few such cases as well, but the ones I meant get a '?' instead because (I think) they trigger this case:

Expected<section_iterator> SecIOrErr = SymI->getSection();
if (!SecIOrErr) {
  consumeError(SecIOrErr.takeError());
  return '?';
}

(These are symbols pointing to zero byte sections.)

This revision was automatically updated to reflect the committed changes.