Hello Joseph, Please help to review this new Multilib feature. It intends to provide user a chance to define their own multilib selection rules. Those rules will be appended to rules generated by gcc script genmultilib. Thus when gcc can't find suitable multilib from its own rules, it can fall back to certain existing multilib according to rules provided by user. This feature is called multilib reuse.
With multilib reuse, we can link a better multilib rather than always using
the default multilib when fail to find exactly matched multilib. This
feature also can help to reduce the total number of multilib variants.
For simplicity, the rules used by multilib reuse are same with the rules in
variable multilib_select. For example, to reuse multilib (in folder dirM and
built with option "optA optB optC") among targets "optA optD optE" and "optA
optF optG", we can define following reuse rules:
MULTILIB_REUSE = dirM optA optD optE;dirM optA optF optG;
The above method requires user to define such rules in Multilib Makefile
fragment and those rules are eventually turned into gcc built-in rules. Any
change to them require to rebuild the gcc. To make it easy to adjust reuse
rules, my patch turns MULTILIB_REUSE into a gcc spec named multilib_reuse.
So follow the way how gcc handle spec, it's easy to change reuse rules
without rebuilding the gcc. Suppose we need to share same multilib with
target "optH optI optJ", we can write following spec file and feed it to
gcc:
*multilib_reuse:
+ dirM optH optI optJ;
In summary, we can use fragment to provide some pre-decided rules and use
spec to change rules on the fly.
Does this feature make sense and is it ok to trunk? Please advise. Thanks.
BR,
Terry
2012-10-10 Terry Guo <terry....@arm.com>
* genmultilib (MULTILIB_REUSE): New macro.
* Makefile.in (s-mlib): Add a new argument MULTILIB_REUSE.
* gcc.c (multilib_reuse): New spec.
(set_multilib_dir): Use multilib_reuse.
gcc-multilib-reuse.patch
Description: Binary data
