> > When testing a extension, it is often necessary for a certain program not to > > need some kind of extension, such as the bitmanip extension, to evaluate the > > performance or codesize of the extension. However, the current multilib > > rules > > will report an error when it is not a superset of the MULTILIB_REQUIRED > > list, > > which will cause the program to be unable to link normally, thus failing to > > achieve the expected purpose. > > Hmm, I have troubles understanding what is going on here. What do you > refer to by saying: "it is not a superset of the MULTILIB_REQUIRED list"?
This is a new matching rule added by kito for the multilib of riscv: https://github.com/gcc-mirror/gcc/commit/d72ca12b846a9f5c01674b280b1817876c77888f > There should be no problem with linking compiled modules together that > make use of different extensions, with the static linker figuring out the > combined set of extensions actually required at run time for the program > loader to consider, as long as the modules do not have contradicting > requirements, e.g. big vs little endianness or RV32 vs RV64. > > Can you give me a specific example (compilation options and multilibs > available) of a failure you refer to? A simple example: 1. Use "--disable-multilib --with-abi =lp64d --with-arch =rv64imafdc_zba_zbb_zbc_zbs" to build the toolchain". 2. Use the toolchain to test the impact of zba_zbb_zbc_zbs extensions on the performance and codesize of some functions or files in the program. In this case, I may need to use the command "-mabi=lp64d -march=rv64imafdc" for the compilation of a specific .c file in the program, which will cause the link to fail and throw the following error: "FATAL ERROR: Can't find suitable multilib set for '-march=rv64imafdc'/'-mabi=lp64d'". This does not satisfy the purpose of the test. I think this needs an option to turn off this check. Users sometimes, just as gcc uses the default multilib when it does not match the appropriate multilib, do not need the `security lock`, and should already understand the risks of using this option. > Is this something that could be solved without resorting to a possibly > dangerous hack, by making use of MULTILIB_REUSE? Regarding the use of MULTILIB_REUSE, I think kito's patch has already been explained and is currently implemented according to the new rules. https://github.com/gcc-mirror/gcc/commit/5ca9980fc86242505ffdaaf62bca1fd5db26550b > > Maciej Thanks, Jin
