[RFC] New features for multilib control

Jeff Law law@redhat.com
Thu Jun 28 03:24:00 GMT 2018


On 06/13/2018 07:56 AM, Matthew Fortune wrote:
> Hi,
> 
> This patch was developed as part of preparing ever more complex multilib
> combinations for the MIPS architecture and aims to solve several problems
> in this area. I've attempted to be quite verbose in the description, so
> that I can explain how I am using various terms as pretty much everyone
> has a different understanding (and I don't claim mine to be 'right'
> either).
> 
> The changes aim to:
> 
> 1) Eliminate the fallback multilib
> The fallback multilib (top level of 'lib') is often annoying because it is
> used for any combination of options that do not match a specific multilib.
> Quite often this default multilib is incompatible with the build options
> that end up linking against it, leading to bizarre link time messages that
> confuse ordinary users.
> 
> 2) Move the default multilib to a subfolder
> Having successfully eliminated the fallback multilib it is also true that
> it would eliminate the 'default' multilib as well. I.e. the library used
> when no relevant user options are supplied. Moving this library to a
> subfolder has two benefits. a) it still exists! and b) the location of
> this library becomes invariant irrespective of which options are
> build-time configured as default.
> 
> 3) Preserve/use invariant paths for multilib variants
> A simplistic multilib specification leads to a nested set of folders,
> where the top level is the left-most multilib directory and the bottom is
> the right most. Introducing a new axis of multilib configuration changes
> this path structure leading to the different library configurations to 
> move around. This is not in itself a problem, as the compiler driver can
> always locate the right path for any given build, but it does cause issues
> when doing configuration management of binary toolchains. When there are
> many different multilibs it is ideal to ship/install only the ones that
> are important and if the paths keep changing over time this process is
> complex and confusing. This issue is effectively solved by the
> MULTI_OSDIRNAMES feature but using it for both sysroot and compiler
> internal libraries is even better.
> 
> 4) Support un-released multilib configurations
> This one sounds weird but it is quite valuable. When an architecture has
> 70+ possible multilib variants but only 40 of them are currently known to
> be needed then only build and release 40 variants. However, if it turns
> out that another configuration becomes useful then it is often handy to
> just build the missing configuration and install it into the pre-existing
> release. So, the driver needs to know about all multilibs and their paths
> but the build process should only build a subset.
> 
> So, the solution...
> 
> Firstly, be verbose about the MULTILIB_OPTIONS needed for a target. Add
> in the default options as well as all the others that may, or could, ever
> be supported by the current compiler features. For MIPS supporting
> MIPS32r1 onwards it looks like this:
> 
> MULTILIB_OPTIONS = muclibc mips32/mips32r2/mips32r6/mips64/mips64r2/mips64r6
> mips16/mmicromips mabi=32/mabi=n32/mabi=64 EB/EL msoft-float mnan=2008
> 
> This does create an enormous matrix of possible configurations so this
> has to be trimmed to the valid set using MULTILIB_REQUIRED. Note that
> the valid set should include any that you may wish to support even if
> you don't want to build/release them. By having the default options in
> then this leads to having two copies of the 'default' multilib; one with
> the options implicitly set and one with them explicitly set.
> 
> Second, remove the multilib with the implicit default options. This
> equates to the '.' multilib entry. To do this use MULTILIB_EXCLUSIONS to
> remove the negated form of every MULTILIB_OPTION:
> 
> MULTILIB_EXCLUSIONS =
> !muclibc/!mips32/!mips32r2/!mips32r6/!mips64/!mips64r2/!mips64r6/!mips16/!mm
> icromips/!mabi=32/!mabi=n32/!mabi=64/!EB/!EL/!msoft-float/!mnan=2008
> 
> Third, set the MULTILIB_OSDIRNAMES to have an entry for every valid
> combination of options and use the '!' modifier. Honestly, I'm not sure
> how/why this works but this leads to both the internal library paths and
> sysroot paths using the OSDIRNAME instead of the nested tree of
> MULTILIB_DIRNAMES. Choose a path for each variant that you will never
> change again; I used an encoded form of the configuration for MIPS:
> 
> MULTILIB_OSDIRNAMES =
> mips32r6/mabi.32/EB/mnan.2008=!mips-r6-hard$(is_newlib)/lib
> 
> Fourth, deal with the fallout from the config-ml.in logic which handles
> the initial 'configure' of a library differently to all of the multilib
> configurations. The basic idea is that since the default multilib will now
> report that it belongs in a subdirectory then, when configuring the top
> level multilib, query the driver for the folder. Later when iterating
> through the multilib specs skip the one that matches the default
> configuration. Each configuration will be built exactly once and all of
> them will be placed in a subfolder leaving the top level install folder
> bare.
> 
> Fifth, restrict the set of multilibs that actually get built for any
> given compiler. This is sort-of a new concept so I added a
> --with-multi-buildlist configure option that points to a file that lists
> all the OSDIRNAME paths that you DO want to build. The config-ml.in file
> queries this list to trim the multilib list. There are existing features
> to trim portions of a multilib list but they are designed to remove a whole
> axis of the configuration and I needed much finer control.
> 
> Sixth, update the fixinc logic so that it too will use the multi-buildlist
> restrictions when installing headers.
> 
> Finally, add default multi-buildlist files that automatically get chosen
> for certain triples.
> 
> I'm aware of a few formatting quirks and other issues in this patch but
> I wanted to share the patch both to get feedback and see if anyone else
> finds it useful to finish it off and help do the required level of testing.
> 
> Comments/feedback welcome.
The core concepts all seem solid to me.  It'd probably be helpful to
give some guidance how to convert existing ports.

This could help with some of the other legacy ports.  For example the
H8, which by default builds a 16bit compiler which, for a variety of
reasons, is incapable of building the C++ runtime.  These days I don't
think we'd want to build any of the 16bit variants at all, but having a
way to drop them in if someone did want them is probably helpful.
Getting the multilib names stable has a lot of value too.

Jeff



More information about the Gcc-patches mailing list