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




Reply via email to