This is an archive of the discontinued LLVM Phabricator instance.

[llvm-nm] Display STT_GNU_IFUNC as 'i'
ClosedPublic

Authored by MaskRay on Dec 21 2019, 10:05 PM.

Diff Detail

Event Timeline

MaskRay created this revision.Dec 21 2019, 10:05 PM
grimar added inline comments.Dec 23 2019, 1:10 AM
llvm/test/tools/llvm-nm/ifunc.test
2

Add a file comment?

llvm/tools/llvm-nm/llvm-nm.cpp
1136

Why not to place the new logic inside getSymbolNMTypeChar ?
It would be consistent with STB_GNU_UNIQUE I think.

MaskRay marked an inline comment as done.Dec 23 2019, 11:50 AM
MaskRay added inline comments.
llvm/tools/llvm-nm/llvm-nm.cpp
1136

Place the new logic inside getSymbolNMTypeChar will be more complex.

For both global and local symbols, the key is the lower case i...

grimar added inline comments.Dec 24 2019, 12:22 AM
llvm/tools/llvm-nm/llvm-nm.cpp
1136

Ok, that behavior makes sence I think.
What about handling the STB_GNU_UNIQUE here too?
(Because at this point this looks like it solves the same thing as STB_GNU_UNIQUE,
but in the different way, what looks inconsistent).

Also, would it be better to do the following?

else if (WasmObjectFile *Wasm = dyn_cast<WasmObjectFile>(&Obj))
  Ret = getSymbolNMTypeChar(*Wasm, I);
else if (ELFObjectFileBase *ELF = dyn_cast<ELFObjectFileBase>(&Obj)) {
 ...
}
else
 llvm_unreachable(...);

(for me it wasn't obvious that is is OK to use elf_symbol_iterator(I) before
cast<ELFObjectFileBase>(Obj). It was not clear that iterator have the same safe cast
inside).

MaskRay updated this revision to Diff 235225.Dec 24 2019, 9:53 AM

Add llvm_unreachable

MaskRay updated this revision to Diff 235226.Dec 24 2019, 9:56 AM
MaskRay marked an inline comment as done.

Simplify

grimar accepted this revision.Dec 24 2019, 11:14 PM

LGTM

This revision is now accepted and ready to land.Dec 24 2019, 11:14 PM
MaskRay updated this revision to Diff 235286.Dec 25 2019, 9:47 AM
MaskRay marked an inline comment as done.

Add a file-level comment to ifunc.test

This revision was automatically updated to reflect the committed changes.

I guess this isn't a real-world use case, but did you consider testing the interaction between STB_GNU_UNIQUE and STT_GNU_IFUNC? For all other types, the unique binding trumped the type, so seeing it different is a little odd.

I guess this isn't a real-world use case, but did you consider testing the interaction between STB_GNU_UNIQUE and STT_GNU_IFUNC? For all other types, the unique binding trumped the type, so seeing it different is a little odd.

binutils-gdb/bfd/syms.c:bfd_decode_symclass

  if (symbol->flags & BSF_GNU_INDIRECT_FUNCTION)
    return 'i';
  if (symbol->flags & BSF_WEAK)
    {
      /* If weak, determine if it's specifically an object
	 or non-object weak.  */
      if (symbol->flags & BSF_OBJECT)
	return 'V';
      else
	return 'W';
    }
  if (symbol->flags & BSF_GNU_UNIQUE)
    return 'u';

Our rule matches GNU nm.

With regard to the interaction, STB_GNU_UNIQUE describes a property of a data symbol, while STT_GNU_IFUNC describes a property of a function symbol. So they cannot be mixed.