| Message ID | 20230814035707.11272-1-yangyujie@loongson.cn |
|---|---|
| State | New |
| Headers | show |
| Series | [v1,1/6] LoongArch: a symmetric multilib subdir layout | expand |
On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > However, for LoongArch, we do not want such a "toplevel" library > installation since the default ABI may change. We expect all > multilib variants of libraries to be installed to their designated > ABI-specific subdirs (e.g. base/lp64d) of the GCC libdir, so that > the default ABI can be configured arbitrarily (with --with-abi) > while the gcc libdir layout stays consistent. This could be > helpful for the distribution packaging of GCC libraries. Have you tested a --disable-multilib configuration? To me with -- disable-configuration everything should be still in the toplevel directory, not any sub-directory. /* snip */ > ChangeLog: > > * config-ml.in: add loongarch support. Allow overriding Use a tab, not 8 white spaces. Likewise for all patches in the series. > toplevel multisubdir.
On Mon, 2023-08-14 at 13:38 +0800, Xi Ruoyao wrote: > > > However, for LoongArch, we do not want such a "toplevel" library > > installation since the default ABI may change. We expect all > > multilib variants of libraries to be installed to their designated > > ABI-specific subdirs (e.g. base/lp64d) of the GCC libdir, so that > > the default ABI can be configured arbitrarily (with --with-abi) > > while the gcc libdir layout stays consistent. This could be > > helpful for the distribution packaging of GCC libraries. > > Have you tested a --disable-multilib configuration? To me with -- > disable-configuration everything should be still in the toplevel I mean --disable-multilib configuration, not "--disable-configuration". > directory, not any sub-directory.
On Mon, Aug 14, 2023 at 01:38:40PM +0800, Xi Ruoyao wrote: > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > > > However, for LoongArch, we do not want such a "toplevel" library > > installation since the default ABI may change. We expect all > > multilib variants of libraries to be installed to their designated > > ABI-specific subdirs (e.g. base/lp64d) of the GCC libdir, so that > > the default ABI can be configured arbitrarily (with --with-abi) > > while the gcc libdir layout stays consistent. This could be > > helpful for the distribution packaging of GCC libraries. > > Have you tested a --disable-multilib configuration? To me with -- > disable-configuration everything should be still in the toplevel > directory, not any sub-directory. That's a good point, sorry I missed --disable-multilib here. However, you don't really need --disable-multilib since the libraries are only built once in the default ABI configuration as long as --with-multilib-list does not request anything more than that. Maybe we should force-enabling multilib in all cases.
On Mon, 2023-08-14 at 15:37 +0800, Yujie Yang wrote: > On Mon, Aug 14, 2023 at 01:38:40PM +0800, Xi Ruoyao wrote: > > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > > > > > However, for LoongArch, we do not want such a "toplevel" library > > > installation since the default ABI may change. We expect all > > > multilib variants of libraries to be installed to their designated > > > ABI-specific subdirs (e.g. base/lp64d) of the GCC libdir, so that > > > the default ABI can be configured arbitrarily (with --with-abi) > > > while the gcc libdir layout stays consistent. This could be > > > helpful for the distribution packaging of GCC libraries. > > > > Have you tested a --disable-multilib configuration? To me with -- > > disable-configuration everything should be still in the toplevel > > directory, not any sub-directory. > > That's a good point, sorry I missed --disable-multilib here. > > However, you don't really need --disable-multilib since > the libraries are only built once in the default ABI configuration > as long as --with-multilib-list does not request anything more than > that. > > Maybe we should force-enabling multilib in all cases. I really don't like this. Why must I always remind my self "hey, this is LoongArch, there is a different directory layout" when I don't need multilib at all?
On Mon, Aug 14, 2023 at 03:48:53PM +0800, Xi Ruoyao wrote: > On Mon, 2023-08-14 at 15:37 +0800, Yujie Yang wrote: > > On Mon, Aug 14, 2023 at 01:38:40PM +0800, Xi Ruoyao wrote: > > > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > > > > > > > However, for LoongArch, we do not want such a "toplevel" library > > > > installation since the default ABI may change. We expect all > > > > multilib variants of libraries to be installed to their designated > > > > ABI-specific subdirs (e.g. base/lp64d) of the GCC libdir, so that > > > > the default ABI can be configured arbitrarily (with --with-abi) > > > > while the gcc libdir layout stays consistent. This could be > > > > helpful for the distribution packaging of GCC libraries. > > > > > > Have you tested a --disable-multilib configuration? To me with -- > > > disable-configuration everything should be still in the toplevel > > > directory, not any sub-directory. > > > > That's a good point, sorry I missed --disable-multilib here. > > > > However, you don't really need --disable-multilib since > > the libraries are only built once in the default ABI configuration > > as long as --with-multilib-list does not request anything more than > > that. > > > > Maybe we should force-enabling multilib in all cases. > > I really don't like this. Why must I always remind my self "hey, this > is LoongArch, there is a different directory layout" when I don't need > multilib at all? > AFAIK, the two main uses of the multisubdir layout are in the C++ header directory and the GCC libdir (where libgcc.a resides), respectively. The GCC libdir is fine since they are private to a user's GCC build. However, the C++ header directory is shared across the system unless an alternative sysroot is chosen, so the consisentency of the multilib layout matters. So theoretically, the toplevel libraries should have the same ABI under the the target triplet. However, for many architectures, the "--with-abi + MULTILIB_DEFAULT" scheme may cause the toplevel to be configured to have different meanings. So I think it's also a reasonable approach that we just simply eliminate the ambiguous toplevel libraries and use a symmetric layout instead.
On Mon, 2023-08-14 at 18:18 +0800, Yujie Yang wrote: > On Mon, Aug 14, 2023 at 03:48:53PM +0800, Xi Ruoyao wrote: > > On Mon, 2023-08-14 at 15:37 +0800, Yujie Yang wrote: > > > On Mon, Aug 14, 2023 at 01:38:40PM +0800, Xi Ruoyao wrote: > > > > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > > > > > > > > > However, for LoongArch, we do not want such a "toplevel" library > > > > > installation since the default ABI may change. We expect all > > > > > multilib variants of libraries to be installed to their designated > > > > > ABI-specific subdirs (e.g. base/lp64d) of the GCC libdir, so that > > > > > the default ABI can be configured arbitrarily (with --with-abi) > > > > > while the gcc libdir layout stays consistent. This could be > > > > > helpful for the distribution packaging of GCC libraries. > > > > > > > > Have you tested a --disable-multilib configuration? To me with -- > > > > disable-configuration everything should be still in the toplevel > > > > directory, not any sub-directory. > > > > > > That's a good point, sorry I missed --disable-multilib here. > > > > > > However, you don't really need --disable-multilib since > > > the libraries are only built once in the default ABI configuration > > > as long as --with-multilib-list does not request anything more than > > > that. > > > > > > Maybe we should force-enabling multilib in all cases. > > > > I really don't like this. Why must I always remind my self "hey, this > > is LoongArch, there is a different directory layout" when I don't need > > multilib at all? > > > > AFAIK, the two main uses of the multisubdir layout are in the C++ > header directory and the GCC libdir (where libgcc.a resides), respectively. > The GCC libdir is fine since they are private to a user's GCC build. > However, the C++ header directory is shared across the system unless > an alternative sysroot is chosen, so the consisentency of the multilib > layout matters. The C++ header directory should also be considered private to the GCC build. AFAIK no distro supports "overwriting a part of the system", so you cannot just install a custom GCC build and overwrite the system C++ header directory. For a cross compiler, the C++ header directory is $prefix/$target_triple/include/c++/$gcc_version/$multi_dir, the C++ header in $sysroot/usr/include/c++ (if it ever exists) will not be used at all. > So theoretically, the toplevel libraries should have the same ABI under > the the target triplet. However, for many architectures, the > "--with-abi + MULTILIB_DEFAULT" scheme may cause the toplevel to be > configured to have different meanings. https://gcc.gnu.org/PR104085 is an example of the issue caused by the different meaning. > So I think it's also a reasonable approach that we just simply eliminate > the ambiguous toplevel libraries and use a symmetric layout instead. I don't like the inconsistency among different GCC ports. If all ports use the same approach I'll not object.
On Mon, 2023-08-14 at 19:16 +0800, Xi Ruoyao wrote: > On Mon, 2023-08-14 at 18:18 +0800, Yujie Yang wrote: > > On Mon, Aug 14, 2023 at 03:48:53PM +0800, Xi Ruoyao wrote: > > > On Mon, 2023-08-14 at 15:37 +0800, Yujie Yang wrote: > > > > On Mon, Aug 14, 2023 at 01:38:40PM +0800, Xi Ruoyao wrote: > > > > > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > > > > > > > > > > > However, for LoongArch, we do not want such a "toplevel" library > > > > > > installation since the default ABI may change. We expect all > > > > > > multilib variants of libraries to be installed to their designated > > > > > > ABI-specific subdirs (e.g. base/lp64d) of the GCC libdir, so that > > > > > > the default ABI can be configured arbitrarily (with --with-abi) > > > > > > while the gcc libdir layout stays consistent. This could be > > > > > > helpful for the distribution packaging of GCC libraries. > > > > > > > > > > Have you tested a --disable-multilib configuration? To me with -- > > > > > disable-configuration everything should be still in the toplevel > > > > > directory, not any sub-directory. > > > > > > > > That's a good point, sorry I missed --disable-multilib here. > > > > > > > > However, you don't really need --disable-multilib since > > > > the libraries are only built once in the default ABI configuration > > > > as long as --with-multilib-list does not request anything more than > > > > that. > > > > > > > > Maybe we should force-enabling multilib in all cases. > > > > > > I really don't like this. Why must I always remind my self "hey, this > > > is LoongArch, there is a different directory layout" when I don't need > > > multilib at all? > > > > > > > AFAIK, the two main uses of the multisubdir layout are in the C++ > > header directory and the GCC libdir (where libgcc.a resides), respectively. > > The GCC libdir is fine since they are private to a user's GCC build. > > However, the C++ header directory is shared across the system unless > > an alternative sysroot is chosen, so the consisentency of the multilib > > layout matters. > > The C++ header directory should also be considered private to the GCC > build. AFAIK no distro supports "overwriting a part of the system", so > you cannot just install a custom GCC build and overwrite the system C++ > header directory. For a cross compiler, the C++ header directory is > $prefix/$target_triple/include/c++/$gcc_version/$multi_dir, the C++ > header in $sysroot/usr/include/c++ (if it ever exists) will not be used > at all. > > > So theoretically, the toplevel libraries should have the same ABI under > > the the target triplet. However, for many architectures, the > > "--with-abi + MULTILIB_DEFAULT" scheme may cause the toplevel to be > > configured to have different meanings. > > https://gcc.gnu.org/PR104085 is an example of the issue caused by the > different meaning. > > > So I think it's also a reasonable approach that we just simply eliminate > > the ambiguous toplevel libraries and use a symmetric layout instead. > > I don't like the inconsistency among different GCC ports. If all ports > use the same approach I'll not object. I came up with another idea. What if we: 1. Keep the "default" ABI libs in the toplevel directory. There is *always* a default ABI so treating it specially is not really nonsense. 2. Create a symlink for consistency. For example, if --with-abi=lp64d, - -with-multilib-list=lp64d,lp64s: * /usr/lib/gcc/loongarch64-linux-gnu/14.0.0 contains the lp64d libraries. * /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/lp64s contains the lp64s libraries. * /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/lp64d is a symlink to "." Then we can refer to the lp64d libgcc.a with both /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/lp64d/libgcc.a, and /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/libgcc.a. For referring to the default multilib, the non-suffixed /usr/lib/gcc/loongarch64-linux-gnu/14.0.0 path should be used; for referring lp64d (no matter what the default is), /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/lp64d should be used. The symlink can be created by the GCC building system or manually by the distro maintainer (or gcc packager). Thoughts?
> I came up with another idea. What if we: > > 1. Keep the "default" ABI libs in the toplevel directory. There is > *always* a default ABI so treating it specially is not really nonsense. > 2. Create a symlink for consistency. For example, if --with-abi=lp64d, - > -with-multilib-list=lp64d,lp64s: > > * /usr/lib/gcc/loongarch64-linux-gnu/14.0.0 contains the lp64d > libraries. > * /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/lp64s contains the lp64s > libraries. > * /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/lp64d is a symlink to "." > > Then we can refer to the lp64d libgcc.a with both > /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/lp64d/libgcc.a, and > /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/libgcc.a. > > For referring to the default multilib, the non-suffixed > /usr/lib/gcc/loongarch64-linux-gnu/14.0.0 path should be used; for > referring lp64d (no matter what the default is), > /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/lp64d should be used. > > The symlink can be created by the GCC building system or manually by the > distro maintainer (or gcc packager). > > Thoughts? > > -- > Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and > Technology, Xidian University Yes, this also eliminates the duplicate build. In this case, the symlink would not really be necessary since the toplevel directory is searched by the driver for all ABI configurations anyways. It is even easier to implement: 1. (gcc/config.gcc) stipulate that loongarch64-linux-gnu == --with-abi=lp64d, loongarch64-linux-gnuf64 == --with-abi=lp64d, loongarch64-linux-gnuf32 == --with-abi=lp64f, loongarch64-linux-gnusf == --with-abi=lp64s, and no customization is allowed. (maybe we can simply remove --with-abi?) 2. (config-ml.in) delete the "default" multisubdir from ${multidirs}. (which is base/lp64d for --with-abi=lp64d) No other tweaking in config-ml.in is required. So this seems to be canonical. The only problem is, I understand that triplets are essential to the GNU build system, but should they always imply the default ABI to be used when the compiler is invoked without an argument?
diff --git a/config-ml.in b/config-ml.in index 68854a4f16c..914cafb4b50 100644 --- a/config-ml.in +++ b/config-ml.in @@ -383,6 +383,18 @@ mips*-*-*) done fi ;; +loongarch*-*-*) + old_multidirs="${multidirs}" + multidirs="" + for x in ${old_multidirs}; do + case "$x" in + `${CC-gcc} --print-multi-directory`) : ;; + *) multidirs="${multidirs} ${x}" ;; + esac + done + + with_multisubdir=`${CC-gcc} --print-multi-directory` + ;; msp430-*-*) if [ x$enable_no_exceptions = xno ] then @@ -509,7 +521,7 @@ multi-do: compiler="$(CC)"; \ for i in `$${compiler} --print-multi-lib 2>/dev/null`; do \ dir=`echo $$i | sed -e 's/;.*$$//'`; \ - if [ "$${dir}" = "." ]; then \ + if [ "$${dir}" = "." ] || [ "/$${dir}" = "$(MULTISUBDIR)" ]; then \ true; \ else \ if [ -d ../$${dir}/$${lib} ]; then \ @@ -595,6 +607,12 @@ if [ -z "${with_multisubdir}" ]; then ml_subdir= ml_builddotdot= : # ml_srcdotdot= # already set +elif [ "${ml_toplevel_p}" = yes ]; then + : # When ml_* is set by ${host}. + ml_subdir="/${with_multisubdir}" + ml_builddotdot= + ml_builddotdot_link=`echo ${with_multisubdir} | sed -e 's:[^/][^/]*:..:g'`/ + : # ml_srcdotdot= # already set else ml_subdir="/${with_multisubdir}" # The '[^/][^/]*' appears that way to work around a SunOS sed bug. @@ -654,6 +672,25 @@ mv Makefile.tem ${Makefile} if [ "${ml_toplevel_p}" = yes ]; then +# If multisubdir is set on the top level, create a symbolic link +# to cope with in-tree regression tests (see dejagnu: libgloss.exp). + +if [ -n "${with_multisubdir}" ]; then + if [ "${ml_verbose}" = --verbose ]; then + echo "Creating multilib link (${with_multisubdir}) for the default library." + echo "pwd: `${PWDCMD-pwd}`" + fi + + ml_origdir=`${PWDCMD-pwd}` + ml_libdir=`echo "$ml_origdir" | sed -e 's,^.*/,,'` + # cd to top-level-build-dir/${with_target_subdir} + cd .. + + mkdir -p "${with_multisubdir}" + ln -sf "${ml_builddotdot_link}${ml_libdir}" "${with_multisubdir}/" + cd "${ml_origdir}" +fi + # We must freshly configure each subdirectory. This bit of code is # actually partially stolen from the main configure script. FIXME. diff --git a/libgcc/config/loongarch/t-loongarch b/libgcc/config/loongarch/t-loongarch index 2a7dbf6ca83..791a8c52f24 100644 --- a/libgcc/config/loongarch/t-loongarch +++ b/libgcc/config/loongarch/t-loongarch @@ -5,3 +5,19 @@ softfp_int_modes := si di softfp_extensions := softfp_truncations := softfp_exclude_libgcc2 := n + +# Since we employ a symmetric multilib layout, i.e. the default lib +# always gets installed to its ${multisubdir} (see config-ml.in), +# we need to copy it (again) into the GCC directory +# (without the multilib suffix) in order to keep some regression +# tests working (libstdc++), because "too many things knows +# about the layout of the build tree" for now (libgcc/Makefile.in). + +# If we are on the top level (default library), +# copy libgcc into gcc build directory. +ifneq ($(MULTIDO),true) +all: install-default-lib +.PHONY: install-default-lib +install-default-lib: libgcc.a + -$(LN_S) .$(MULTISUBDIR)/libgcc.a $(gcc_objdir)/libgcc.a +endif
Multilib in gcc is asymmetric. i.e. a "default" / "toplevel" library variant is always built and installed, and: * it is installed directly under the gcc libdir (with no suffix); * it is selected / searched / linked against when the gcc driver does not receive any option from MULTILIB_OPTIONS. Meanwhile, multilib options from MULTILIB_OPTIONS may add suffixes (--print-multi-lib) to this base directory and find compatible library variants there. However, for LoongArch, we do not want such a "toplevel" library installation since the default ABI may change. We expect all multilib variants of libraries to be installed to their designated ABI-specific subdirs (e.g. base/lp64d) of the GCC libdir, so that the default ABI can be configured arbitrarily (with --with-abi) while the gcc libdir layout stays consistent. This could be helpful for the distribution packaging of GCC libraries. This patch achieves this by overriding ${with_multisubdir} of the "toplevel" library and disabling the duplicate "multilib" variant (which exists because LA's driver always generates a normalized "-mabi=" option from self_spec even if it is not given on the command line, causing the semantics of "toplevel" library to be duplicate with a non-toplevel one). Other architectures stay unaffected as long as they do not override ${with_multisubdir} in config-ml.in. ChangeLog: * config-ml.in: add loongarch support. Allow overriding toplevel multisubdir. libgcc/ChangeLog: * config/loongarch/t-loongarch: make symlinks of toplevel libgcc.a under gcc/ for passing regression tests. --- config-ml.in | 39 ++++++++++++++++++++++++++++- libgcc/config/loongarch/t-loongarch | 16 ++++++++++++ 2 files changed, 54 insertions(+), 1 deletion(-)