RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.
Checks
Commit Message
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.
Therefore, the compilation option is added to avoid riscv_multi_lib_check()
interruption of compilation.
gcc/ChangeLog:
* config/riscv/elf.h (LIB_SPEC): Do not run riscv_multi_lib_check() when
-mdisable-multilib-check.
* config/riscv/riscv.opt: New.
---
gcc/config/riscv/elf.h | 2 +-
gcc/config/riscv/riscv.opt | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
Comments
> 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.
>
> Therefore, the compilation option is added to avoid riscv_multi_lib_check()
> interruption of compilation.
I think it's dangerous to remove the check, but I can understand there
are some cases where we really do not want the `security lock`,
so I am OK with introducing a new option to disable that.
but plz add documentation to the option into gcc/doc/invoke.texi
and mention it will just use default multilib and MIGHT not be correct
in some cases.
> --- a/gcc/config/riscv/riscv.opt
> +++ b/gcc/config/riscv/riscv.opt
> @@ -295,3 +295,7 @@ Enum(riscv_autovec_lmul) String(m8) Value(RVV_M8)
> -param=riscv-autovec-lmul=
> Target RejectNegative Joined Enum(riscv_autovec_lmul) Var(riscv_autovec_lmul) Init(RVV_M1)
> -param=riscv-autovec-lmul=<string> Set the RVV LMUL of auto-vectorization in the RISC-V port.
> +
> +mdisable-multilib-check
I would like to rename that to mno-multilib-check since that is more
like all other gcc option conventions.
> +Target Bool Var(riscv_disable_multilib_check) Init(0)
You don't need Var(riscv_disable_multilib_check) and Init(0) since no
one check the value
And you need RejectNegative to prevent gcc accept -mno-disable-multilib-check
> +Disable multilib checking by riscv_multi_lib_check().
`riscv_multi_lib_check()` is meanless for users since it's
implementation detail.
`Disable multilib checking; use the default multilib if a compatible
one is not found.`
On Tue, 23 May 2023, Jin Ma via Gcc-patches 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"?
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?
Is this something that could be solved without resorting to a possibly
dangerous hack, by making use of MULTILIB_REUSE?
Maciej
> > 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
On Mon, May 29, 2023 at 10:53 AM Jin Ma <jinma@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
> > > > 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
Yes, but with "--with-arch=rv64imafdc" building toolchains, the library will not contain
zba_zbb_zbc_zbs extensions, so how can we quickly and easily eliminate the impact of not
using zba_zbb_zbc_zbs extensions in a certain program on program performance and codesize?
Although-mno-multilib-check is unsafe, it is useful during the development and testing phases.
>
> >
> > 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
On 5/28/23 21:46, Jin Ma 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
>
> Yes, but with "--with-arch=rv64imafdc" building toolchains, the library will not contain
> zba_zbb_zbc_zbs extensions, so how can we quickly and easily eliminate the impact of not
> using zba_zbb_zbc_zbs extensions in a certain program on program performance and codesize?
>
> Although-mno-multilib-check is unsafe, it is useful during the development and testing phases.
But I'm not sure that's a good reason to include an unsafe option like
this in the official GCC sources.
This is the kind of thing that I'd tend to think belongs as a local change.
jeff
On Mon, 29 May 2023, Jin Ma wrote:
> > 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.
Thank you. This is weird and contrary to how things used to work since
forever (not necessarily an argument by itself, but our usual arrangement
seemed reasonable). So whenever `--disable-multilib' has been used for
GCC configuration I would expect all the multilib logic to be suppressed
(as it used to be) and all assembler output just being thrown at the
linker hoping for the best (the linker has its own logic to decide what's
compatible enough and what's not; modulo any bugs of course).
So has the change in semantics actually been intentional?
Maciej
On 5/30/23 08:48, Maciej W. Rozycki wrote:
> On Mon, 29 May 2023, Jin Ma wrote:
>
>>> 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.
>
> Thank you. This is weird and contrary to how things used to work since
> forever (not necessarily an argument by itself, but our usual arrangement
> seemed reasonable). So whenever `--disable-multilib' has been used for
> GCC configuration I would expect all the multilib logic to be suppressed
> (as it used to be) and all assembler output just being thrown at the
> linker hoping for the best (the linker has its own logic to decide what's
> compatible enough and what's not; modulo any bugs of course).
>
> So has the change in semantics actually been intentional?
Just as important, this scenario is not one that we really want to cater
the compiler's behavior to. We should not be introducing an unsafe
option like this into the compiler sources -- engineers that need to do
this kind of testing can carray this kind of patch in their downstream
trees.
jeff
@@ -29,7 +29,7 @@ along with GCC; see the file COPYING3. If not see
#undef LIB_SPEC
#define LIB_SPEC \
"--start-group -lc %{!specs=nosys.specs:-lgloss} --end-group " \
- "%{!nostartfiles:%{!nodefaultlibs:%{!nolibc:%{!nostdlib:%:riscv_multi_lib_check()}}}}"
+ "%{!mdisable-multilib-check:%{!nostartfiles:%{!nodefaultlibs:%{!nolibc:%{!nostdlib:%:riscv_multi_lib_check()}}}}}"
#undef STARTFILE_SPEC
#define STARTFILE_SPEC "crt0%O%s crtbegin%O%s"
@@ -295,3 +295,7 @@ Enum(riscv_autovec_lmul) String(m8) Value(RVV_M8)
-param=riscv-autovec-lmul=
Target RejectNegative Joined Enum(riscv_autovec_lmul) Var(riscv_autovec_lmul) Init(RVV_M1)
-param=riscv-autovec-lmul=<string> Set the RVV LMUL of auto-vectorization in the RISC-V port.
+
+mdisable-multilib-check
+Target Bool Var(riscv_disable_multilib_check) Init(0)
+Disable multilib checking by riscv_multi_lib_check().