In D84770#2210049, @sameerarora101 wrote:

In D84770#2208826, @smeenai wrote:

In D84770#2204147, @sameerarora101 wrote:

I think I need to add V8 support under llvm/include/llvm/TextAPI/MachO/Architecture.def here:

///
/// ARM64 architectures sorted by cpu sub type id.
///
ARCHINFO(arm64, MachO::CPU_TYPE_ARM64, MachO::CPU_SUBTYPE_ARM64_ALL, 64)
ARCHINFO(arm64e, MachO::CPU_TYPE_ARM64, MachO::CPU_SUBTYPE_ARM64E, 64)

What should be the first element for that tuple in case of V8 (arm64_v8 or arm64v8 or maybe something else) ? Thanks.

Hmm, what necessitates the TAPI patch? arm64_v8 seems fine to me, though @ributzka and @cishida should weigh in there.

Converting a yaml file with Subtype V8 to an object file requires this patch. I was trying to add a test for V8, but my yaml was incorrectly parsed as an object file with unknown architecture.

In D85594#2207080, @gkm wrote:

@tschuett, I prefer not to do anything that involves semantics for DriverKit, since I don't have any domain knowledge. For that matter, perhaps I shouldn't even follow-through with this diff, which I only embarked upon at your suggestion because the original author of the MachO -platform_version diff (I commandeered it) had a TODO comment. I can code-monkey the TBDv4 testcase via simple substitution, but what about TBDv1 .. TBDv3? IDK, and don't want to spend time determining minimum version# for DriverKit. Do you know that?

Thanks for fixing this! one nit but LGTM

the landed patch has applied MaskRay's comments.

adopintg jhenderson's comments to increase Readablity & Coding Guidelines

Updating to address comments, add more const correctness, fix casing on FileCheck

the lint corrections will be/have been made in the revision that lands.

Updating this patch to just create inlining framework support, and I will attach lib/Object & nm support in a seperate patch

LGTM, Jürgen approved via email as well.

updating Kuba's patch with tests

LGTM, thank you for cleaning this up.

LGTM

will resolve the warning: invalid case style for variable '...' [readability-identifier-naming] in a future patch since it'll cause mismatching conventions through the whole file.

Updating to use LLVM_FALLTHROUGH for cases

This indirection seems like unnecessary work. Could you reimplement this as a direct conversion to std::string?

LGTM, thank you!

small comment, otherwise LGTM

nit: probably should update [TAPI] to [llvm][TextAPI/MachO] in the commit header.

LGTM, thanks!

Updating to fix copy/paste error

Fix a few typos in comments

Add simulator + tests

Reduce inplace limit for TargetList

Update: Enforce Integer value for swift abi version

Additional Cleanup.

Address comments from review

Add enum to MetaDataSection

Inline PlatformSet Output

In D66160#1666925, @kcc wrote:

Hi.

The asan bot is unhappy:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/35078/steps/check-llvm%20asan/logs/stdio

Please fix or revert ASAP.

10406==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 312 byte(s) in 1 object(s) allocated from:

#0 0x514d38 in operator new(unsigned long) /b/sanitizer-x86_64-linux-fast/build/llvm-project/compiler-rt/lib/asan/asan_new_delete.cc:105
#1 0x15627c9 in llvm::yaml::MappingTraits<llvm::MachO::InterfaceFile const*>::NormalizedTBD::denormalize(llvm::yaml::IO&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/TextAPI/MachO/TextStub.cpp:403:20
#2 0x1548510 in ~MappingNormalization /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/YAMLTraits.h:1321:24
#3 0x1548510 in llvm::yaml::MappingTraits<llvm::MachO::InterfaceFile const*>::mapping(llvm::yaml::IO&, llvm::MachO::InterfaceFile const*&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/TextAPI/MachO/TextStub.cpp:592
#4 0x1542bbe in doMapping<const llvm::MachO::InterfaceFile *> /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/YAMLTraits.h:961:3
#5 0x1542bbe in yamlize<const llvm::MachO::InterfaceFile *, llvm::yaml::EmptyContext> /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/YAMLTraits.h:1085
#6 0x1542bbe in operator>><std::__1::vector<const llvm::MachO::InterfaceFile *, std::__1::allocator<const llvm::MachO::InterfaceFile *> > > /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/YAMLTraits.h:1696
#7 0x1542bbe in llvm::MachO::TextAPIReader::get(llvm::MemoryBufferRef) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/TextAPI/MachO/TextStub.cpp:633
#8 0x139fd27 in llvm::object::TapiUniversal::TapiUniversal(llvm::MemoryBufferRef, llvm::Error&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Object/TapiUniversal.cpp:25:17
#9 0x13a0b0d in llvm::object::TapiUniversal::create(llvm::MemoryBufferRef) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Object/TapiUniversal.cpp:50:42
#10 0x122d5e9 in llvm::object::createBinary(llvm::MemoryBufferRef, llvm::LLVMContext*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Object/Binary.cpp:91:12
#11 0x51cf7c in dumpSymbolNamesFromFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llvm-nm/llvm-nm.cpp:1795:7
#12 0x51bbf7 in for_each<std::__1::__wrap_iter<std::__1::basic_string<char> *>, void (*)(std::__1::basic_string<char> &)> /b/sanitizer-x86_64-linux-fast/build/libcxx_build_asan/include/c++/v1/algorithm:886:9
#13 0x51bbf7 in for_each<llvm::cl::list<std::__1::basic_string<char>, bool, llvm::cl::parser<std::string> > &, void (*)(std::__1::basic_string<char> &)> /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/ADT/STLExtras.h:1159
#14 0x51bbf7 in main /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llvm-nm/llvm-nm.cpp:2163
#15 0x7f08c0c232e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)

[TextAPI] add num bits to architecture

• [TextAPI] move archs to architecture.def

In D66160#1661284, @plotfi wrote:

Does this addition mean that llvm-nm should eventually include some support for other text formats like ifs/elfabi etc? I think this could be pretty useful for writing tests, which I assume is part of the motivation here?

Add 64bit symbol reading

LGTM

bridgeOS hasn't been added to llvm triple yet, so it's fine to exclude it for now.
also I have a patch I'm adding very soon that takes in llvm::triple and does the arch/platform mapping so you won't need to. I'll update this file when it comes out.