This more or less matches what GNU ld does.
The clang_rt.builtins-$arch cases are a bit problematic; an alternative would be to trim the library name at the first period, and just have it match against libclang_rt.
Differential D38937
[LLD] [COFF] Exclude certain static libraries and object files when exporting all symbols mstorsjo on Oct 15 2017, 2:11 PM. Authored by
Details This more or less matches what GNU ld does. The clang_rt.builtins-$arch cases are a bit problematic; an alternative would be to trim the library name at the first period, and just have it match against libclang_rt.
Diff Detail Event TimelineComment Actions At this point I feel like we should define a function bool shouldExport(Defined *Sym) or something, so that we can move the code to that function. Comment Actions Sounds like a good idea. How do you suggest to handle the exclude StringSets in that case - recreate them in each function invocation? Or have a static StringSet<> ExcludeSymbols in the global scope? For future direction; GNU ld has got options for adding symbols and libraries to the exclude libs, so in case someone actually needs and wants that feature, we might need to add support for such options. I haven't felt a great need for it so far though, since I don't think I've ever seen it used. Comment Actions I don't know if this is a good idea, but since the number of strings you need to check is small, you may be able to just iterate over the list like this? for (StringRef S : {"libgcc", "libgcc_s", ...}) if (LibName == S) return false; Comment Actions I feel that would end up pretty unwieldy. Additionally, the set of symbols to exclude is different depending on the architecture. The symbol/lib/object sets should be easy to encapsulate in a class though - I'll update the diff with such a suggestion. Comment Actions I don't see a reason to use OO over plain functions in this patch, but this is probably okay. We can revisit it later. But I feel we are having too many functions for MinGW in Driver.cpp, so I was thinking that it might be a good idea to great MinGW.{h,cpp} in the COFF directory to put MinGW-related stuff there. What do you think? Comment Actions The reason for OO was (as you probably guess) keeping the sets around for each invocation. It might be a case of premature optimization. The alternative while keeping them around, with plain functions, would be to store the sets in the calling context and passing them to the function, and at that point, wrapping them up in a class seemed to simplify the code.
That's probably sensible. Do you want a preparatory patch doing that, and then rebasing this one on top of that? Comment Actions LGTM given that you are going to create a follow-up patch to move MinGW-related stuff to new files. |