public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Xi Ruoyao <xry111@xry111.site>
To: YunQiang Su <yunqiang.su@cipunited.com>, gcc-patches@gcc.gnu.org
Cc: macro@orcam.me.uk, doko@debian.org, jeffreyalaw@gmail.com
Subject: Re: [PATCH] MIPS: fix building on multiarch platform
Date: Wed, 21 Sep 2022 23:08:51 +0800	[thread overview]
Message-ID: <c8f6663967d170dd51e2bc33481618e1beffb313.camel@xry111.site> (raw)
In-Reply-To: <20220921113118.520824-1-yunqiang.su@cipunited.com>

On Wed, 2022-09-21 at 11:31 +0000, YunQiang Su wrote:
> On platforms that support multiarch, such as Debian,
> the filesystem hierarchy doesn't fellow the old Irix style:
>         lib & lib/<multiarch> for native
>         lib64 for N64 on N32/O32 systems
>         lib32 for N32 on N64/O32 systems
>         libo32 for O32 on N64/N32 systems
> 
> Thus we cannot
>  #define STANDARD_STARTFILE_PREFIX_1
>  #define STANDARD_STARTFILE_PREFIX_2
> on N32 or N64 systems, else collect2 won't look for libraries
> on /lib/<multiarch>.
> 
> gcc/ChangeLog:
>         * configure.ac: AC_DEFINE(ENABLE_MULTIARCH, 1)
>         * configure: Regenerated.
>         * config.in: Regenerated.
>         * config/mips/mips.h: don't define STANDARD_STARTFILE_PREFIX_1
>           if ENABLE_MULTIARCH is defined.
>         * config/mips/t-linux64: define correct multiarch path when
>           multiarch is enabled.
> ---
>  gcc/config.in             |  6 ++++++
>  gcc/config/mips/mips.h    |  2 ++
>  gcc/config/mips/t-linux64 | 21 ++++++++++++++++++++-
>  gcc/configure             |  4 ++++
>  gcc/configure.ac          |  3 +++
>  5 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config.in b/gcc/config.in
> index 6ac17be189e..b2ce6361327 100644
> --- a/gcc/config.in
> +++ b/gcc/config.in
> @@ -2312,6 +2312,12 @@
>  #endif
>  
>  
> +/* Specify if mutliarch is enabled. */
> +#ifndef USED_FOR_TARGET
> +#undef ENABLE_MULTIARCH
> +#endif
> +
> +
>  /* The size of `dev_t', as computed by sizeof. */
>  #ifndef USED_FOR_TARGET
>  #undef SIZEOF_DEV_T
> diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
> index 74b6e11aabb..fe7f5b274b9 100644
> --- a/gcc/config/mips/mips.h
> +++ b/gcc/config/mips/mips.h
> @@ -3427,6 +3427,7 @@ struct GTY(())  machine_function {
>  
>  /* If we are *not* using multilibs and the default ABI is not ABI_32
> we
>     need to change these from /lib and /usr/lib.  */
> +#ifndef ENABLE_MULTIARCH
>  #if MIPS_ABI_DEFAULT == ABI_N32
>  #define STANDARD_STARTFILE_PREFIX_1 "/lib32/"
>  #define STANDARD_STARTFILE_PREFIX_2 "/usr/lib32/"
> @@ -3434,6 +3435,7 @@ struct GTY(())  machine_function {
>  #define STANDARD_STARTFILE_PREFIX_1 "/lib64/"
>  #define STANDARD_STARTFILE_PREFIX_2 "/usr/lib64/"
>  #endif
> +#endif

Should we just remove STANDARD_STARTFILE_PREFIX_{1,2} unconditionally? 
I just took a look and the only Linux ports using these macros are MIPS
and LoongArch (borrowed these macros from MIPS, I guess).  On a non-
multilib distro /usr/lib is likely used, and on multilib distros the
macros are not used anyway.

>  /* Load store bonding is not supported by micromips and fix_24k.  The
>     performance can be degraded for those targets.  Hence, do not bond for
> diff --git a/gcc/config/mips/t-linux64 b/gcc/config/mips/t-linux64
> index 2fdd8e00407..37d176ea309 100644
> --- a/gcc/config/mips/t-linux64
> +++ b/gcc/config/mips/t-linux64
> @@ -20,7 +20,26 @@ MULTILIB_OPTIONS = mabi=n32/mabi=32/mabi=64
>  MULTILIB_DIRNAMES = n32 32 64
>  MIPS_EL = $(if $(filter %el, $(firstword $(subst -, ,$(target)))),el)
>  MIPS_SOFT = $(if $(strip $(filter MASK_SOFT_FLOAT_ABI, $(target_cpu_default)) $(filter soft, $(with_float))),soft)
> -MULTILIB_OSDIRNAMES = \
> +ifeq (yes,$(enable_multiarch))
> +  ifneq (,$(findstring gnuabi64,$(target)))
> +    MULTILIB_OSDIRNAMES = \
> +       ../lib32$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \
> +       ../libo32$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \
> +       ../lib$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
> +  else ifneq (,$(findstring gnuabin32,$(target)))
> +    MULTILIB_OSDIRNAMES = \
> +       ../lib$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \
> +       ../libo32$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \
> +       ../lib64$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
> +  else
> +    MULTILIB_OSDIRNAMES = \
> +       ../lib32$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \
> +       ../lib$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \
> +       ../lib64$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
> +  endif
> +else
> +  MULTILIB_OSDIRNAMES = \
>         ../lib32$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \
>         ../lib$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \
>         ../lib64$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
> +endif

Hmm, I don't think we should touch this.  The default setting of
MULTILIB_OSDIRNAMES is simply not designed to suit all distros (at least
for now) and many distros are patching it.  Change it here won't give
the distro maintainers any benefit, but will force them to rebase the
patch.

If we want to make the distro maintainers' life easier we'd make a
global decision (for all ports) and maybe add some configuration options
for MULTILIB_OSDIRNAMES.


-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

  reply	other threads:[~2022-09-21 15:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 11:31 YunQiang Su
2022-09-21 15:08 ` Xi Ruoyao [this message]
2022-09-21 16:03   ` Maciej W. Rozycki
2022-09-23 12:35   ` YunQiang Su

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c8f6663967d170dd51e2bc33481618e1beffb313.camel@xry111.site \
    --to=xry111@xry111.site \
    --cc=doko@debian.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=macro@orcam.me.uk \
    --cc=yunqiang.su@cipunited.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).