[...] > > Please help to review this new Multilib feature. It intends to > provide > > user > > Your patch doesn't include documentation for fragments.texi (which > needs to define the semantics without reference to the details of what > gcc.c's internal datastructures for multilibs, as output by genmultilib, > might look like). > > I am unconvinced that directly adding to the drivers' internal > datastructures like this is a sensible interface for specifying > multilib choice in target makefile fragments. >
Very appreciate your review and comments. Here is an updated patch which
follows the approaches used in current multilib implementation. With this
update, the following statement means target represented by "optC optD" can
reuse existing multilib built by options "optA optB":
MULTILIB_REUSE = optA/optB=optC/optD
To convert such statements to data structure used by multilib_raw, I
refactor codes in genmultilib into two functions combo_to_dir and
options_output. Then use combo_to_dir to convert left part into multilib
folder name and use options_output to convert right part into option list.
Inside gcc.c, those reuse rules will be used once gcc can't figure out
multilib that exactly matches current command line options.
I build trunk code with this patch along with --enable-multilib for targets
arm-none-eabi/x86/m6800/mips/powerpc. No problem found.
Is this patch OK? Please comment.
BR,
Terry
2012-11-08 Terry Guo <terry....@arm.com>
* genmultilib (combo_to_dir): New function.
(options_output): New function.
(MULTILIB_REUSE): New argument.
* Makefile.in (s-mlib): Add a new argument MULTILIB_REUSE.
* gcc.c (multilib_reuse): New spec.
(set_multilib_dir): Use multilib_reuse.
multilib-reuse-v2.patch
Description: Binary data
