Add llvm-nm to list of LLVM tools built with stdlib standalone mode

[kubamracek]

This is to fix the two test failures from https://ci.swift.org/job/swift-PR-stdlib-with-toolchain-osx/7/console.

[kubamracek]

@swift-ci please test

[compnerd]

Please restrict this behaviour to standalone builds (on Darwin). Im worried that this is going to complicate the tests as this restricts the ability to get fixes into llvm-nm (via libObject or other changes).

[kubamracek]

@swift-ci test stdlib with toolchain

[gottesmm]

My main concern is if llvm-nm has a feature that we rely on. I would go the other way and make it so that standalone only uses llvm-nm and that we add a lit feature of some sort that says that one should assume no llvm-tools. Need to think about it more.

[kubamracek]

By the way the Xcode supplied “nm” actually is llvm-nm. That’s why I’m suggesting this change.

[gottesmm]

Yes, but it might be old and incompatible though. We have hit this in the past with other tools.

[kubamracek]

Any other preferred solution? The others I can think of:

• Make the two tests unsupported on stdlib standalone builds.
• Add a "REQUIRES: llvm-nm" feature that will not be available in standalone builds.
• Find some other stable reliable way to list weak symbols, not requiring llvm-nm.
• Actually start building llvm-nm in the stdlib standalone builds, paying the extra 3 minutes build time cost. (My least favorite solution.)

Practically, though, I would bet that for the purposes that the two tests are using llvm-nm today (listing weak symbols), the Darwin OS version of "nm" is going to be pretty stable and reliable (unless you have an Xcode that's many years old, which actually won't be able to build recent Swift anyway.)

[kubamracek]

@swift-ci please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 9f8ce644a1ebbb46e56e845c83d50ab67a7295f5

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 9f8ce644a1ebbb46e56e845c83d50ab67a7295f5

[compnerd]

I think I prefer 3 and then 1. Not all platforms have nm, and allowing as many tests to be portable is preferable so that people testing on other platforms don't break.

That said, the build already requires clang at certain points, so the LLVM dependency is there. So seems that expecting llvm-nm isn't entirely unreasonable.

[kubamracek]

How about introducing a new python script that would have a more specific function: List all weak symbols from a target binary, or list all exported symbols from the binary. On Darwin, we'd use "nm" for this, on Linux, "objdump". I really don't see the need for llvm-nm (and to pay the cost of building it) if all we need is list of exports and weak symbols.

We could then use it like this: RUN: %{python} %utils/list-weak-symbols.py > %t-weak

[compnerd]

What about windows? What about building with MSVC vs clang? I think that using llvm-nm which is really a pretty small tool is well worth the 1 minute or so that it takes. Adding additional python scripts is also a tax - python isn't as portable - it has a lot of issues with long paths and directory structures on Windows. llvm-nm nicely avoids all of those issues.

[kubamracek]

Maybe I misread what you mentioned before. Do you actually want to include llvm-nm in the list of tools we build for standalone builds?

[kubamracek]

@swift-ci test stdlib with toolchain

[kubamracek]

@swift-ci please test stdlib with toolchain

[kubamracek]

@swift-ci please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 02d6eeefa3ee28d7e3aa770997bf3579272b6529

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 02d6eeefa3ee28d7e3aa770997bf3579272b6529

[kubamracek]

@swift-ci please test

[gottesmm]

LGTM

[compnerd]

Maybe I misread what you mentioned before. Do you actually want to include llvm-nm in the list of tools we build for standalone builds?

Sorry, yes, I think it is better to include llvm-nm in the list of tools we build.