[lld] [LLD] [COFF] Fix crashes for conflicting exports with -export-all-symbols (PR #190492)

[Martin Storsjö via llvm-commits]

mstorsjo wrote:

> I wonder if a more practical approach would be to silently prefer the non-export-all variant in those cases, similar to how directives can be overridden by a def file or command-line options. This would allow specifying things like explicit ordinals without generating warnings. (This is not a strong opinion; if you prefer to keep the warning, that is fine with me as well and the code looks good to me.)

That sounds like a reasonable thing to do in general.

However, I wonder if that should be a separate patch on top of this one. This one doesn't really take any stance on what the existing implementation should do, it just tries to avoid hitting the `llvm_unreachable` in `exportSourceName`. We could then separately change the implementation to not warn but prefer the def file in this case.

But on the other hand, if we make that a separate step on top, then only the first patch (fixing the crash) might qualify for backporting to 22.x, while the second one would have to remain only in git main.

What do you think?

(As a side note, in the case of the original report of this issue, it's actually the LLD produced autoexport entry which is right, and the def file which is wrong. They disagree about whether a symbol is a data symbol or not. When ffmpeg builds shared libraries, it used version scripts for limiting which symbols to export and which to hide. LLD doesn't support version scripts for the mingw target, so ffmpeg falls back on a script to apply the wildcard patterns from the version script, on the symbol listings from `nm` or similar. This script doesn't currently distinguish between function and data symbols. Normally this works fine, but if one explicitly adds `-Wl,--export-all-symbols`, one would run into this issue.)


https://github.com/llvm/llvm-project/pull/190492