joerg added a comment. Talking from the perspective of having had to deal with thousands of packages in pkgsrc over the years: it is naive to believe that there isn't a lot of software that calls the linker directly for various reasons. As such, it is very important to have a useful configuration in the linker by default. Such a configuration is by its very nature target specific. This doesn't mean it can't be done in a cross-compiler friendly way, on the contrary. Over the years NetBSD has been pushing its toolchain to be as similar for the native build and a cross-target as reasonable possible. Modulo the build time choices in the config.h sense, the only difference between the native and cross tools is the built-in default of the former.
Clang works extremely well in that regard and perfectly supports a universal toolchain. LLD should as well. Consistent behavior of ELF across different OS is a fiction, as such some OS and/or CPU family specific defaults are naturally different. This can be grouped in general: (1) The target operating system specified either from the builtin default, the name of the tool (triple-ld), an option like clang's --target or if desirable the name of the emulation when specified. I don't have a strong reason for supporting the last as it is typically not unique even with binutils and more a case of historic legacy than useful feature. For the perspective of supporting both native and cross toolchains, the first three options are enough and when using the compiler driver, the first two will generally work fine. (2) The target CPU family. While it can be partially guessed from the object files, there are fun expects. ARM instruction encodings are one of the pecularities a linker has to deal with for example. Is BX a valid jump instruction? (3) Whether the target CPU family is the primary ABI. This can generally not be determined from the object files and can affect the default search paths. Hard vs soft floating point is a good example here. Other cases are easier like linking i386 binaries on x86_64. N32 vs N64 on MIPS is more difficult again. This is a bit tricky in that it often can be drived only from the emulation name. In terms of architecture, it doesn't need much, but it needs some thought. Identifying the target OS is likely the easiest. Most of the rest is OS specific adjustment. Having access to the binary name and the the arguments should be enough though. Doing it properly avoids the fun of having to patch a lot of software without costing that much in terms of code. Repository: rLLD LLVM Linker CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56215/new/ https://reviews.llvm.org/D56215 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
