search for: _objc_class_

...I've forgotten about, will need to be a _significantly_ different format than what Apple has as their "TBD" format. Apple's format also has a bunch of special cases in it to make it easier to use for their platform, but a rather less generic tool. E.g., symbols starting with "_OBJC_CLASS_$" are recorded in the "objc-classes" field with the prefix removed, instead of just recording it as-is. So, I'd also caution that while the project of "import apple's libtapi into LLVM for LLD/MachO" and "Make a scheme to do interface shared-libs for ELF"...

...rences.size() != 1 ) throwf("__objc_classrefs element missing reloc (count=%ld) for target class in %s", references.size(), fOwner.getPath()); const char* targetName = references[0]->getTargetName(); if ( strncmp(targetName, "_OBJC_CLASS_$_", 14) == 0 ) asprintf((char**)&fSynthesizedName, "objc-class-ref-to-%s", &targetName[14]); else asprintf((char**)&fSynthesizedName, "objc-class-ref-to-%s", targetName); } } The Mach-O lin...

Benifits of TBD: 1) It's human readable and diffs on TBDs correspond to changes in the ABI. Diffs can be automatically added to review processes to ensure that changes to the ABI are reviewed. The TBDs also document your precise ABI. 2) The size is smaller which means they can be shipped in an SDK instead of binaries to reduce the size of an SDK 3) Stubs are producible from TBDs (or should be)

On Mon, Apr 9, 2018 at 10:11 PM, John Ericson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Regardless of any of that, given that TBD files _are_ an integral part > of the apple platform, supporting them is certainly a necessity in order to > have a working apple linker. So, if making LLD work for Apple/MachO is the > justification for adding TBD support to LLVM, that