Parse -h (supported by GNU ar as well)
Address review comments

I wish we can create a new function for MRI error reporting but as it stands, runMRIScript can call readLibrary, addChildMember, and addMember which can in turn call fail or failIfError, so fail has to be aware of the MRI line number. +@grimar @jhenderson in case they have suggestions.

LGTM, just a few nits and a requested test.

Wrap two other error messages

Wrap operation names in ''

Delete !

Thanks for the review!

a workaround -> workarounds.

LG. D65313 added the support for GNU style output.

Looks good. The behavior was introduced in D66623.

Two passes assign InputSectionBases to OutputSections:

Delete unrelated InputSectionIterator (I tried changing InputSectionDescription::sections from an InputSection* vector to InputSectionBase* vector, but the result is not clean - many subsequent passes assume the elements of sections are InputSections. The size of OutputSection is not a big concern, so I added another field instead)

separate-segments -> separate-loadable-segments

This patch is the (awful) reason I posted D67325 before this one. 🤔

Update description

In D67325#1666249, @peter.smith wrote:

Apologies for the delay in responding. I've gone through in a bit more detail. Just to make sure I understand and hopefully give an alternative explanation to anyone else following:

Some findings related to the topic. There are two kinds of unresolved references: 1) from object files 2) from shared objects. --unresolved-symbols= toggles both bits while -z (un)defs and --(no-)allow-shlib-undefined toggles one bit, respectively. I personally favor the fine-grained options over --unresolved-symbols=

In D67287#1665215, @xbolva00 wrote:

Thanks for review/advices!

Address review comments

Address review comments

Looks reasonable. Verified that check-lld (a heavy llvm-objdump user) also passed.

Update a comment

In D67301#1665171, @rnk wrote:

In D67301#1664700, @MaskRay wrote:

I hope at least for ELF, you can keep the "_Z" prefix check. It doesn't need the ObjC "___Z" extension.

Are you sure? Surely users could use -fblocks to get those manglings, or use ObjC on Linux.

There is a clash between allocateHeaders and fixSectionAlignments and your change resolves this by only running allocateHeaders in the linkerscript. I can see that this would work, but I think that this could be at the expense of missing some of the logic in allocateHeaders, and leaving a point to diverge in the future. As this is making me a bit nervous at the moment I'd like to try and understand the conflict a bit better and whether there is a better way of doing this (there may not be).

Address review comments

This change is not NFC. This will cause every port of LLD to demangle more names than which were allowed before.

I recently came across the <internal> issue, and was just reminded of the presence of the patch. I am in favor of this change.

In D67388#1664465, @grimar wrote:

In D67388#1664463, @MaskRay wrote:

In D67388#1664420, @grimar wrote:

In D67388#1664414, @ruiu wrote:

In D67388#1664387, @grimar wrote:

I looked at the sample provided and I think that if I was a new user, I'd find not clear what is "<internal>" probably.
What about including something like "<internal> is usually a symbol defined by linker" line to the header?

Also I am not sure what is situation now, but before we used to report "<internal>" for linker script defined symbols
in our messages sometimes. Would be nice to have a test for that case.

"<internal>" does not represent a symbol but a file. Ideally we should give more meaningful name for each virtual file, but I think that's beyond the scope of this patch.

If it reports "<internal>" for a symbol from a linker script still - it should be mentioned in the header. Otherwise it might be not clear where a sybmol is coming from.

If we want to have a meaningful file name for synthesized sections, linker synthesized symbols, and SymbolAssignment symbols, we have to create a new InputFile::Kind

std::string lld::toString(const InputFile *f) {
  if (!f)  // this can be null for various reasons above
    return "<internal>";

I suggested the same previously: D45375