Hello Joseph, Thanks for your comments. When start to work on Multilib for ARM backend, I do run into some limitations of GCC Multilib mechanism. The most important one is just as what you said in thread http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html, e.g. the limitation of MULTILIB_MATCHES. So I am very curious of the progress of your proposal. Is it possible for you to share it? I am also very willing to provide help if needed.
Best regards, Terry > -----Original Message----- > From: Joseph Myers [mailto:jos...@codesourcery.com] > Sent: Sunday, September 11, 2011 6:58 PM > To: Terry Guo > Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw > Subject: Re: [RFC][GCC, Multilib]Make GCC more easier for user to > select and build extra libraries for ARM targets. > > On Sun, 11 Sep 2011, Terry Guo wrote: > > > This patch intends to implement a convenient interface for user to > customize > > the final Multilibs according to their real requirements. There is no > > intention to override the default Multilib set, instead it only build > > "extra" libraries besides them. Specifically the extra Multilibs can > be > > selected by user through a new configure option > > "--with-extra-multilibs=A-COMMA-SEPARATED-TARGET-LIST". For example > if user > > want to build extra library for cortex-m0, cortex-m3 and cortex-m4, > the > > configure option would be > > "--with-extra-multilibs=armv6s-m,armv7-m,armv7e-m". > > This seems very similar to the --with-multilib-list option for SH and > x86_64. I think you should use the same name and share the same > implementation as far as possible - certainly, you need to explain how > what you have done compares to that option and justify differences. If > the difference is whether the multilibs add to or replace the default > list, maybe allow "default," to appear in the argument to > --with-multilib-list to indicate that the default list is added to > rather > than replaced. > > > +@item --with-extra-multilibs=@var{list} @itemx > > +--without-extra-multilibs Specify what extra multilibs to build > besides > > You have @itemx on the wrong line here. > > > Index: gcc/config/arm/t-armv7e-m > > =================================================================== > > --- gcc/config/arm/t-armv7e-m (revision 0) > > +++ gcc/config/arm/t-armv7e-m (revision 0) > > @@ -0,0 +1,16 @@ > > +#Build below library for ARM armv7e-m architecture. > > +# armv7e-m/ -mthumb -march=armv7e-m > > + > > +MULTILIB_OPTIONS += march=armv7e-m > > + > > +MULTILIB_DIRNAMES += armv7e-m > > + > > +MULTILIB_EXCEPTIONS += march=armv7e-m* > > +MULTILIB_EXCEPTIONS += marm*/march=armv7e-m* > > +MULTILIB_EXCEPTIONS += mfloat-abi=hard/march=armv7e-m* > > +MULTILIB_EXCEPTIONS += mthumb/mfloat-abi=hard/march=armv7e-m* > > +MULTILIB_EXCEPTIONS += m*/march=armv7e-m/march* > > + > > +MULTILIB_MATCHES += march?armv7e-m=mcpu?cortex-m4 > > + > > +MULTILIB_OSDIRNAMES += mthumb/march.armv7e-m=!armv7e-m > > I don't think having such massive manually maintained files for each > architecture is sustainable. Note that when the SH configure option > was > enhanced > > 2009-04-17 Andrew Stubbs <a...@codesourcery.com> > > it *removed* a load of such files. > > m68k/t-mlibs uses awk to process .def files to work out appropriate > multilib settings in different cases. That seems a much more > sustainable > way of producing these settings than entering them all manually. > > -- > Joseph S. Myers > jos...@codesourcery.com