Fix genmultilib reuse rule checks for large sets of option combinations.
genmultilib computes combination_space, a list of all combinations of
options in MULTILIB_OPTIONS that might have multilibs built for them
(some of which may end up not having multilibs built for them, and
some of those may end up being mapped to other multilibs with
MULTILIB_REUSE). It is then used to validate the right hand part of
MULTILIB_REUSE rules, checking with expr that combination_space
matches a basic regular expression derived from that right hand part.
There are two problems with this approach to validation:
* It requires that right hand part to have options in the same order
as in MULTILIB_OPTIONS, in contradiction to the documentation of
MULTILIB_REUSE saying that order does not matter there.
* combination_space can be so large that the expr call fails with an
E2BIG error. I have a local ARM configuration with 40 multilibs but
3840 combinations of options from MULTILIB_OPTIONS (so 3839 listed
in combination_space, since it doesn't list the default multilib)
and 996 MULTILIB_REUSE rules. This generates a combination_space
string longer than the Linux kernel's MAX_ARG_STRLEN (PAGE_SIZE *
32, the limit on the length of a single argv string), so that expr
cannot be run.
This patch changes the validation approach to generate a much shorter
extended regular expression for any sequence of multilib options in
any order, and uses that for the validation instead.
Tested with a build for arm-none-eabi --with-multilib-list=aprofile
(as a configuration that uses MULTILIB_REUSE).
* genmultilib (combination_space): Remove variable.
Validate reuse rules against regular expression for any sequence
of multilib options in any order.
From-SVN: r249703