On Mon, May 29, 2023 at 10:53 AM Jin Ma <ji...@linux.alibaba.com> wrote: > > > > 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 feel this case should be build with --with-arch =rv64imafdc and test with -march=rv64imafdc and -march=rv64imafdc_zba_zbb_zbc_zbs, but anyway I am OK with option :P > > 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