MaskRay added a comment. In D85474#2344823 <https://reviews.llvm.org/D85474#2344823>, @compnerd wrote:
> In D85474#2343393 <https://reviews.llvm.org/D85474#2343393>, @MaskRay wrote: > >> In D85474#2343356 <https://reviews.llvm.org/D85474#2343356>, @dexonsmith >> wrote: >> >>> In D85474#2343326 <https://reviews.llvm.org/D85474#2343326>, @MaskRay wrote: >>> >>>> In D85474#2342365 <https://reviews.llvm.org/D85474#2342365>, @compnerd >>>> wrote: >>>> >>>>> Is there a reason to not use the existing `-mlinker-version=` option and >>>>> expanding that beyond just Darwin targets? I feel like having the same >>>>> option would be much nicer. >>> >>> I agree with @compnerd that it seems better to reuse this if possible. I >>> wasn't around back then, but I have to assume it was named generically in >>> order to enable that. >>> >>>> `-mlinker-version` is currently a macOS option. We could reuse it but that >>>> would be confusing: when -fuse-ld=lld is specified, does it specify the >>>> lld version? (No) >>> >>> Maybe it should? > > Actually, I think it has to - there is some work underway to add MachO > support to lld - so we will need to have this be the lld version anyway in > that case. > >> Then there is an expanded use case, -fuse-ld= which is just a driver option >> for linking, will now affect code generation. > > I don't see this as an expanded use case - this is precisely the use case it > is intended for. It is specifying the linker - the linker may have a > different set of features and code generation (and the driver behaviour) need > to adjust for that. If the linker does not support `.drectve` processing on > PE/COFF, it will need to change the code generation. This seems very much in > scope for the option. This seems to assume the an object file is emitted for one specific linker, a standard system linker or LLD (ELF or Mach-O). How do you communicate the fact that the user wants to emit object files suitable for both the standard system linker and LLD? -fuse-ld=bfd,lld or other variants? This is a much wider design space I somewhat want to avoid. I hope I can see more convincing arguments that -mlinker-version= plus a few other toggles are really better than -fbinutils-version=. I have actually thought about -mlinker-version= when @jyknight or someone else mentioned it. But with more thoughts I don't find it actually better than a very specific -fbinutils-version= which users should immediately know the intention. >>>> There are also GNU as related issues. >>> >>> I don't understand this bit. >> >> This is the main point. Many feature are also related to the version of GNU >> assembler when -fno-integrated-as is specified. > > I could also be using a different assembler than binutils, so controlling > this via a binutils specific option seems less appealing, and seems better to > have the assembler be different from the linker seems better. So do you suggest an option specifically for assembler? -massembler-version? Then how do you communicate the fact that you want to be compatible with GNU as from binutils? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85474/new/ https://reviews.llvm.org/D85474 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
