Generalize error message.

I love the use of StringSwitch! Very cool!

Nice! I noticed that the tests in eh-frame.s only contain failing cases. Are there already success cases tested elsewhere?

After having spoken to @int3 , we decided to adjust the code in a couple ways so I'll be reworking this diff.

Get rid of unnecessary priority variable.

Rename lowestPriority to highestAvailablePriority.

Remove duplicated code representing "maximum priority"

Change PriorityBuilder from a unique pointer to a regular object.

I applied the same idea to config->callGraphProfile. @int3 Could you take a look?

Added config->callGraphProfile to PriorityBuilder

Never mind. I found this is unnecessary.

As I understand, we are zero-ing out the addends of all cfstring sections because we are moving the addend check from the section comparisons to the relocation comparisons. All relocation comparisons (not just those for cfsections) will now check addend equality. LGTM

Add assert statement.

it wouldn't hurt to assert that the offset is indeed zero.

Fix cast.

@int3 I've simplified the code to not use offsets from StringPieces and to just print the StringRef that corresponds to each StringPiece. This is because we no longer do any tail-merging, making offsets unnecessary.

Address comments

rebase

Address comments

Add test with no dead symbols.

Address comments

Update assert

Reverted from declarative style to a more imperative style.

Insert missing period from warning.

Update comments.

Addressed mpark's comments.

In D114735#3232598, @oontvoo wrote:

In D114735#3225835, @Roger wrote:

@int3 could you submit this for me? thanks :)

do you still need help landing this?

Rewrite code in a more declarative style.

Small rename.

Rewrite diff to be more declarative.

In D114737#3216825, @thevinster wrote:

The output from ld64 doesn't look like what lld produces.

You're right that the new dead symbol section is not exactly the same as what ld64 outputs. look lld/test/MachO/dead-strip.s. I followed the precedence set by lld's section for live symbols and basically replicated that for dead symbols. Do you think this needs to be changed?

Squashing separate commits.

@int3 could you submit this for me? thanks :)

I expect this will need some advice but I think it's ready for its initial review.

Address comments

I'm not an Apple/Mach-O developer, and don't really know much, if anything, about the platform or the file format, so take my thoughts with a pinch of salt. However, I wanted to question this:

1. For traditional Unix static libraries, the filenames are largely irrelevant - you can have multiple library members without any issue and it'll just work at link time. This is because such library members are picked based on their symbol names, rather than anything to do with their filenames.
2. If the existing cctools libtool reports a warning rather than an error, why not do the same here? It seems like reporting an error might cause problems where existing users are creating such a library for good reason. NB: if there is no possible good reason, i.e. the library is fundamentally broken, then an error makes sense - see my above point about not being too familiar with the format.

Formatting

Formatting

Addressing comments