`nm` output symbols not referenced by `LC_SYMTAB` - c

Question

Why ?
I am trying to reproduce the behavior of nm.
Problem
The command nm /usr/libexec/sharingd output some stranges symbols like :
[..]
00000001001d7570 t -[_TtC8sharingd19SDAirDropHandlerIPA canHandleTransfer]
00000001001d8070 t -[_TtC8sharingd19SDAirDropHandlerIPA initWithTransfer:bundleIdentifier:]
00000001001d7ed0 t -[_TtC8sharingd19SDAirDropHandlerIPA singleItemActionTitle]
00000001001d75f0 t -[_TtC8sharingd19SDAirDropHandlerIPA suitableContentsDescription]
00000001001d7580 t -[_TtC8sharingd19SDAirDropHandlerIPA transferTypes]
00000001001e45a0 t -[_TtC8sharingd27SDAirDropContactHashManager .cxx_destruct]
00000001001daf60 t -[_TtC8sharingd27SDAirDropContactHashManager acquireTokenForIdentifier:]
00000001001dcf70 t -[_TtC8sharingd27SDAirDropContactHashManager init]
00000001001be700 t <redacted function 7904>
00000001001beb50 t <redacted function 7905>
00000001001bebf0 t <redacted function 7906>
00000001001bf050 t <redacted function 7907>
00000001001bf100 t <redacted function 7908>
00000001001bf3a0 t <redacted function 7909>
00000001001bf490 t <redacted function 7910>
00000001001bf4d0 t <redacted function 7911>
00000001001bf540 t <redacted function 7912>
00000001001bf580 t <redacted function 7913>
00000001001bf590 t <redacted function 7914>
00000001001bf5b0 t <redacted function 7915>
00000001001bf5d0 t <redacted function 7916>
00000001001bf5e0 t <redacted function 7917>
00000001001bf5f0 t <redacted function 7918>
[..]
My version of nm doesn't output these symbols.
Where do they come from ?
Ascertainments
1.
Part of those symbols name (i.e. _TtC8sharingd19SDAirDropHandlerIPA or canHandleTransfer) are present in the string table of the mach-o file.
However, they're present as different strings.
2.
The symbol <redacted function xxx> is not present anywhere in the mach-o file.
3.
Theses symbols are not references by the LC_SYMTABS load command.

Answer 1

I also reproduced the nm command and I also did not handle this case. Thank you for sharing.
Looking at the LLVM source code, it seems that:
if nm encounters a LC_FUNCTION_STARTS (function starts segment), then it will get different (function?) addresses.
It checks that each of theses addresses is already in the symbol table.
If it is not, then comes the case that we do not handle:
See the comment at line 1672: "See this address is not already in the table symbol fake up an nlist for it."
// See this address is not already in the symbol table fake up an
// nlist for it.
if (!found) {
NMSymbol F = {};
F.Name = "<redacted function X>";
F.Address = FoundFns[f] + BaseSegmentAddress;
F.Size = 0;
// There is no symbol in the nlist symbol table for this so we set
// Sym effectivly to null and the rest of code in here must test for
// it and not do things like Sym.getFlags() for it.
F.Sym = BasicSymbolRef();
F.SymFlags = 0;
F.NType = MachO::N_SECT;
F.NSect = 0;
StringRef SegmentName = StringRef();
StringRef SectionName = StringRef();
for (const SectionRef &Section : MachO->sections()) {
Section.getName(SectionName);
SegmentName = MachO->getSectionFinalSegmentName(
Section.getRawDataRefImpl());
F.NSect++;
if (F.Address >= Section.getAddress() &&
F.Address < Section.getAddress() + Section.getSize()) {
F.Section = Section;
break;
}
}
if (SegmentName == "__TEXT" && SectionName == "__text")
F.TypeChar = 't';
else if (SegmentName == "__DATA" && SectionName == "__data")
F.TypeChar = 'd';
else if (SegmentName == "__DATA" && SectionName == "__bss")
F.TypeChar = 'b';
else
F.TypeChar = 's';
F.NDesc = 0;
F.IndirectName = StringRef();
SymbolList.push_back(F);
if (FoundFns[f] == lc_main_offset)
FOS << "<redacted LC_MAIN>";
else
FOS << "<redacted function " << f << ">";
FOS << '\0';
FunctionStartsAdded++;
}
And that's how these symbols seem to appear.