Message ID | 20220921135108.3324737-7-adhemerval.zanella@linaro.org |
---|---|
State | Committed |
Commit | 9dc4e29f630c6ef8299120b275e503321dc0c8c7 |
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2CA6E3856DFE for <patchwork@sourceware.org>; Wed, 21 Sep 2022 13:53:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2CA6E3856DFE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1663768428; bh=NS+5yEtxUeXWejx8bfHLU02mwR2MHWzSa/YDRPZRzko=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=JcDfnMwwD5IAfFdWs6nxzWMg4W0r0zjjOroM7OL+us5VptSHybblPbPenOSZWKZtT cLsIidxhGjuKwU1G8MPXVX/zlYV9aTKvJGsKi7pypJPo6a+PbaWPblO9kpMjuNlq/H wFJgbIkz6RnvrKlj030N0HojNNfasz3pctKpZkbc= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id 06A4C3858406 for <libc-alpha@sourceware.org>; Wed, 21 Sep 2022 13:51:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 06A4C3858406 Received: by mail-oi1-x22a.google.com with SMTP id j188so8185576oih.0 for <libc-alpha@sourceware.org>; Wed, 21 Sep 2022 06:51:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date; bh=NS+5yEtxUeXWejx8bfHLU02mwR2MHWzSa/YDRPZRzko=; b=rsKdyniF7JQmBawCjWusQR8J6dLQ7Hf4LhoT+8gScxsIjdA6vUSQqt/rBZKcsPAelX rOMXSgSFiOQrZq2ba9ZJVyfEoMp1bUarBygo/K+q8n4BPzSa+nW0KnWLF5JowOOpdX5X 3LmgmYZhkOMmdphnKeSwhdi+Hbn5Ft7mCGt1FR82AhXI3OW7gJxxyYzW7l/FtlMXB+Js 6ZKEG5pTTfriBujzZAsOW+JYuFh4u7LJTnNjBrVKOskNJcypQpCPoOuT0OcE5DGBxyXO ieFRba5djIhxMrsY4cyIT2+mw+OvyctRTKPeOXSJg8DRxzZNOD4a8eaPLN/FoctGstnU jNhA== X-Gm-Message-State: ACrzQf17aeE11GybDfhY6bodR5cA7rxNDHzlKtwYYYujr/K5I8phCup7 GbYeiCYTAkb7bJjaZBTKy4o6vBtGrxA4GBln X-Google-Smtp-Source: AMsMyM5i4Os3Iwm1UdokeQGUKRhM8xMO4GLueRbl0klQtn6mb4IMG3KWsbc3In5mFBpWC5vMaM6CKA== X-Received: by 2002:a05:6808:140e:b0:350:cdfb:8572 with SMTP id w14-20020a056808140e00b00350cdfb8572mr3868357oiv.9.1663768286092; Wed, 21 Sep 2022 06:51:26 -0700 (PDT) Received: from mandiga.. ([2804:1b3:a7c1:c266:dbbf:9e84:6582:5289]) by smtp.gmail.com with ESMTPSA id a38-20020a05687046a600b0010bf07976c9sm1669476oap.41.2022.09.21.06.51.25 for <libc-alpha@sourceware.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Sep 2022 06:51:25 -0700 (PDT) To: libc-alpha@sourceware.org Subject: [PATCH 6/6] x86: Fix -Os build (BZ #29576) Date: Wed, 21 Sep 2022 10:51:08 -0300 Message-Id: <20220921135108.3324737-7-adhemerval.zanella@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220921135108.3324737-1-adhemerval.zanella@linaro.org> References: <20220921135108.3324737-1-adhemerval.zanella@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Adhemerval Zanella <adhemerval.zanella@linaro.org> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Fix -Os build
|
|
Commit Message
Adhemerval Zanella
Sept. 21, 2022, 1:51 p.m. UTC
The compiler might transform __stpcpy calls (which are routed to __builtin_stpcpy as an optimization) to strcpy and x86_64 strcpy multiarch implementation does not build any working symbol due ISA_SHOULD_BUILD not being evaluated for IS_IN(rtld). Checked on x86_64-linux-gnu. --- sysdeps/x86_64/multiarch/rtld-strcpy.S | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 sysdeps/x86_64/multiarch/rtld-strcpy.S
Comments
On Wed, Sep 21, 2022 at 10:51:08AM -0300, Adhemerval Zanella via Libc-alpha wrote: > The compiler might transform __stpcpy calls (which are routed to > __builtin_stpcpy as an optimization) to strcpy and x86_64 strcpy > multiarch implementation does not build any working symbol due > ISA_SHOULD_BUILD not being evaluated for IS_IN(rtld). Ohhhhhh... that is interesting. This changes the strcpy used in rtld for all x86_64 build options, and I'm going to ACK this, but we may need to revisit this if it shows up in a profile. CC'ing HJ here in case he wants to comment as a machine maintainer. LGTM. No regressions on x86_64. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com> > Checked on x86_64-linux-gnu. > --- > sysdeps/x86_64/multiarch/rtld-strcpy.S | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > create mode 100644 sysdeps/x86_64/multiarch/rtld-strcpy.S > > diff --git a/sysdeps/x86_64/multiarch/rtld-strcpy.S b/sysdeps/x86_64/multiarch/rtld-strcpy.S > new file mode 100644 > index 0000000000..19439c553d > --- /dev/null > +++ b/sysdeps/x86_64/multiarch/rtld-strcpy.S > @@ -0,0 +1,18 @@ > +/* Copyright (C) 2022 Free Software Foundation, Inc. > + This file is part of the GNU C Library. > + > + The GNU C Library is free software; you can redistribute it and/or > + modify it under the terms of the GNU Lesser General Public > + License as published by the Free Software Foundation; either > + version 2.1 of the License, or (at your option) any later version. > + > + The GNU C Library is distributed in the hope that it will be useful, > + but WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + Lesser General Public License for more details. > + > + You should have received a copy of the GNU Lesser General Public > + License along with the GNU C Library; if not, see > + <https://www.gnu.org/licenses/>. */ > + > +#include "../strcpy.S" OK. Uses Makeconfig:sysd-rules-patterns to capture rtld-*. > -- > 2.34.1 >
On Wed, Oct 5, 2022 at 7:10 AM Carlos O'Donell <carlos@redhat.com> wrote: > > On Wed, Sep 21, 2022 at 10:51:08AM -0300, Adhemerval Zanella via Libc-alpha wrote: > > The compiler might transform __stpcpy calls (which are routed to > > __builtin_stpcpy as an optimization) to strcpy and x86_64 strcpy > > multiarch implementation does not build any working symbol due > > ISA_SHOULD_BUILD not being evaluated for IS_IN(rtld). > > Ohhhhhh... that is interesting. This changes the strcpy used in rtld for > all x86_64 build options, and I'm going to ACK this, but we may need to > revisit this if it shows up in a profile. Will this lead to both strcpy and stpcpy in ld.so? Currently there is only stpcpy in ld.so. > CC'ing HJ here in case he wants to comment as a machine maintainer. > > LGTM. > > No regressions on x86_64. > > Reviewed-by: Carlos O'Donell <carlos@redhat.com> > Tested-by: Carlos O'Donell <carlos@redhat.com> > > > Checked on x86_64-linux-gnu. > > --- > > sysdeps/x86_64/multiarch/rtld-strcpy.S | 18 ++++++++++++++++++ > > 1 file changed, 18 insertions(+) > > create mode 100644 sysdeps/x86_64/multiarch/rtld-strcpy.S > > > > diff --git a/sysdeps/x86_64/multiarch/rtld-strcpy.S b/sysdeps/x86_64/multiarch/rtld-strcpy.S > > new file mode 100644 > > index 0000000000..19439c553d > > --- /dev/null > > +++ b/sysdeps/x86_64/multiarch/rtld-strcpy.S > > @@ -0,0 +1,18 @@ > > +/* Copyright (C) 2022 Free Software Foundation, Inc. > > + This file is part of the GNU C Library. > > + > > + The GNU C Library is free software; you can redistribute it and/or > > + modify it under the terms of the GNU Lesser General Public > > + License as published by the Free Software Foundation; either > > + version 2.1 of the License, or (at your option) any later version. > > + > > + The GNU C Library is distributed in the hope that it will be useful, > > + but WITHOUT ANY WARRANTY; without even the implied warranty of > > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > > + Lesser General Public License for more details. > > + > > + You should have received a copy of the GNU Lesser General Public > > + License along with the GNU C Library; if not, see > > + <https://www.gnu.org/licenses/>. */ > > + > > +#include "../strcpy.S" > > OK. Uses Makeconfig:sysd-rules-patterns to capture rtld-*. > > > -- > > 2.34.1 > > >
On 05/10/22 14:21, H.J. Lu wrote: > On Wed, Oct 5, 2022 at 7:10 AM Carlos O'Donell <carlos@redhat.com> wrote: >> >> On Wed, Sep 21, 2022 at 10:51:08AM -0300, Adhemerval Zanella via Libc-alpha wrote: >>> The compiler might transform __stpcpy calls (which are routed to >>> __builtin_stpcpy as an optimization) to strcpy and x86_64 strcpy >>> multiarch implementation does not build any working symbol due >>> ISA_SHOULD_BUILD not being evaluated for IS_IN(rtld). >> >> Ohhhhhh... that is interesting. This changes the strcpy used in rtld for >> all x86_64 build options, and I'm going to ACK this, but we may need to >> revisit this if it shows up in a profile. > > Will this lead to both strcpy and stpcpy in ld.so? Currently there is only > stpcpy in ld.so. I think that is expected behavior if compiler creates a reference for a supported string function in the loader (rtld build pulls the implementation). > >> CC'ing HJ here in case he wants to comment as a machine maintainer. >> >> LGTM. >> >> No regressions on x86_64. >> >> Reviewed-by: Carlos O'Donell <carlos@redhat.com> >> Tested-by: Carlos O'Donell <carlos@redhat.com> >> >>> Checked on x86_64-linux-gnu. >>> --- >>> sysdeps/x86_64/multiarch/rtld-strcpy.S | 18 ++++++++++++++++++ >>> 1 file changed, 18 insertions(+) >>> create mode 100644 sysdeps/x86_64/multiarch/rtld-strcpy.S >>> >>> diff --git a/sysdeps/x86_64/multiarch/rtld-strcpy.S b/sysdeps/x86_64/multiarch/rtld-strcpy.S >>> new file mode 100644 >>> index 0000000000..19439c553d >>> --- /dev/null >>> +++ b/sysdeps/x86_64/multiarch/rtld-strcpy.S >>> @@ -0,0 +1,18 @@ >>> +/* Copyright (C) 2022 Free Software Foundation, Inc. >>> + This file is part of the GNU C Library. >>> + >>> + The GNU C Library is free software; you can redistribute it and/or >>> + modify it under the terms of the GNU Lesser General Public >>> + License as published by the Free Software Foundation; either >>> + version 2.1 of the License, or (at your option) any later version. >>> + >>> + The GNU C Library is distributed in the hope that it will be useful, >>> + but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >>> + Lesser General Public License for more details. >>> + >>> + You should have received a copy of the GNU Lesser General Public >>> + License along with the GNU C Library; if not, see >>> + <https://www.gnu.org/licenses/>. */ >>> + >>> +#include "../strcpy.S" >> >> OK. Uses Makeconfig:sysd-rules-patterns to capture rtld-*. >> >>> -- >>> 2.34.1 >>> >> > >
On Wed, Oct 5, 2022 at 10:38 AM Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> wrote: > > > > On 05/10/22 14:21, H.J. Lu wrote: > > On Wed, Oct 5, 2022 at 7:10 AM Carlos O'Donell <carlos@redhat.com> wrote: > >> > >> On Wed, Sep 21, 2022 at 10:51:08AM -0300, Adhemerval Zanella via Libc-alpha wrote: > >>> The compiler might transform __stpcpy calls (which are routed to > >>> __builtin_stpcpy as an optimization) to strcpy and x86_64 strcpy > >>> multiarch implementation does not build any working symbol due > >>> ISA_SHOULD_BUILD not being evaluated for IS_IN(rtld). > >> > >> Ohhhhhh... that is interesting. This changes the strcpy used in rtld for > >> all x86_64 build options, and I'm going to ACK this, but we may need to > >> revisit this if it shows up in a profile. > > > > Will this lead to both strcpy and stpcpy in ld.so? Currently there is only > > stpcpy in ld.so. > > I think that is expected behavior if compiler creates a reference for a > supported string function in the loader (rtld build pulls the > implementation). strcpy is only generated in dl-profile.os: text data bss dec hex filename 2716 0 72 2788 ae4 dl-profile.os (-O2) 2265 0 72 2337 921 dl-profile.os (-Os) 1840 0 0 1840 730 strcpy.os Should we compile dl-profile.c with -O2 with CFLAGS-dl-profile.c += $(if $(findstring -Os,$(+cflags)), -O2) It will create a smaller ld.so. > > > >> CC'ing HJ here in case he wants to comment as a machine maintainer. > >> > >> LGTM. > >> > >> No regressions on x86_64. > >> > >> Reviewed-by: Carlos O'Donell <carlos@redhat.com> > >> Tested-by: Carlos O'Donell <carlos@redhat.com> > >> > >>> Checked on x86_64-linux-gnu. > >>> --- > >>> sysdeps/x86_64/multiarch/rtld-strcpy.S | 18 ++++++++++++++++++ > >>> 1 file changed, 18 insertions(+) > >>> create mode 100644 sysdeps/x86_64/multiarch/rtld-strcpy.S > >>> > >>> diff --git a/sysdeps/x86_64/multiarch/rtld-strcpy.S b/sysdeps/x86_64/multiarch/rtld-strcpy.S > >>> new file mode 100644 > >>> index 0000000000..19439c553d > >>> --- /dev/null > >>> +++ b/sysdeps/x86_64/multiarch/rtld-strcpy.S > >>> @@ -0,0 +1,18 @@ > >>> +/* Copyright (C) 2022 Free Software Foundation, Inc. > >>> + This file is part of the GNU C Library. > >>> + > >>> + The GNU C Library is free software; you can redistribute it and/or > >>> + modify it under the terms of the GNU Lesser General Public > >>> + License as published by the Free Software Foundation; either > >>> + version 2.1 of the License, or (at your option) any later version. > >>> + > >>> + The GNU C Library is distributed in the hope that it will be useful, > >>> + but WITHOUT ANY WARRANTY; without even the implied warranty of > >>> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > >>> + Lesser General Public License for more details. > >>> + > >>> + You should have received a copy of the GNU Lesser General Public > >>> + License along with the GNU C Library; if not, see > >>> + <https://www.gnu.org/licenses/>. */ > >>> + > >>> +#include "../strcpy.S" > >> > >> OK. Uses Makeconfig:sysd-rules-patterns to capture rtld-*. > >> > >>> -- > >>> 2.34.1 > >>> > >> > > > >
On 05/10/22 15:06, H.J. Lu wrote: > On Wed, Oct 5, 2022 at 10:38 AM Adhemerval Zanella Netto > <adhemerval.zanella@linaro.org> wrote: >> >> >> >> On 05/10/22 14:21, H.J. Lu wrote: >>> On Wed, Oct 5, 2022 at 7:10 AM Carlos O'Donell <carlos@redhat.com> wrote: >>>> >>>> On Wed, Sep 21, 2022 at 10:51:08AM -0300, Adhemerval Zanella via Libc-alpha wrote: >>>>> The compiler might transform __stpcpy calls (which are routed to >>>>> __builtin_stpcpy as an optimization) to strcpy and x86_64 strcpy >>>>> multiarch implementation does not build any working symbol due >>>>> ISA_SHOULD_BUILD not being evaluated for IS_IN(rtld). >>>> >>>> Ohhhhhh... that is interesting. This changes the strcpy used in rtld for >>>> all x86_64 build options, and I'm going to ACK this, but we may need to >>>> revisit this if it shows up in a profile. >>> >>> Will this lead to both strcpy and stpcpy in ld.so? Currently there is only >>> stpcpy in ld.so. >> >> I think that is expected behavior if compiler creates a reference for a >> supported string function in the loader (rtld build pulls the >> implementation). > > strcpy is only generated in dl-profile.os: > > text data bss dec hex filename > 2716 0 72 2788 ae4 dl-profile.os (-O2) > 2265 0 72 2337 921 dl-profile.os (-Os) > 1840 0 0 1840 730 strcpy.os > > Should we compile dl-profile.c with -O2 with > > CFLAGS-dl-profile.c += $(if $(findstring -Os,$(+cflags)), -O2) > > It will create a smaller ld.so. It might be an option to a subsequent patch, but I would avoid trying to outsmart the compiler here since it might generate a smaller in other version and it would most likely be arch-specific (adding even more building complexity).
On Wed, Oct 5, 2022 at 1:43 PM Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> wrote: > > > > On 05/10/22 15:06, H.J. Lu wrote: > > On Wed, Oct 5, 2022 at 10:38 AM Adhemerval Zanella Netto > > <adhemerval.zanella@linaro.org> wrote: > >> > >> > >> > >> On 05/10/22 14:21, H.J. Lu wrote: > >>> On Wed, Oct 5, 2022 at 7:10 AM Carlos O'Donell <carlos@redhat.com> wrote: > >>>> > >>>> On Wed, Sep 21, 2022 at 10:51:08AM -0300, Adhemerval Zanella via Libc-alpha wrote: > >>>>> The compiler might transform __stpcpy calls (which are routed to > >>>>> __builtin_stpcpy as an optimization) to strcpy and x86_64 strcpy > >>>>> multiarch implementation does not build any working symbol due > >>>>> ISA_SHOULD_BUILD not being evaluated for IS_IN(rtld). > >>>> > >>>> Ohhhhhh... that is interesting. This changes the strcpy used in rtld for > >>>> all x86_64 build options, and I'm going to ACK this, but we may need to > >>>> revisit this if it shows up in a profile. > >>> > >>> Will this lead to both strcpy and stpcpy in ld.so? Currently there is only > >>> stpcpy in ld.so. > >> > >> I think that is expected behavior if compiler creates a reference for a > >> supported string function in the loader (rtld build pulls the > >> implementation). > > > > strcpy is only generated in dl-profile.os: > > > > text data bss dec hex filename > > 2716 0 72 2788 ae4 dl-profile.os (-O2) > > 2265 0 72 2337 921 dl-profile.os (-Os) > > 1840 0 0 1840 730 strcpy.os > > > > Should we compile dl-profile.c with -O2 with > > > > CFLAGS-dl-profile.c += $(if $(findstring -Os,$(+cflags)), -O2) > > > > It will create a smaller ld.so. > > It might be an option to a subsequent patch, but I would avoid trying to outsmart > the compiler here since it might generate a smaller in other version and it would > most likely be arch-specific (adding even more building complexity). > Fair enough. LGTM. Thanks.
diff --git a/sysdeps/x86_64/multiarch/rtld-strcpy.S b/sysdeps/x86_64/multiarch/rtld-strcpy.S new file mode 100644 index 0000000000..19439c553d --- /dev/null +++ b/sysdeps/x86_64/multiarch/rtld-strcpy.S @@ -0,0 +1,18 @@ +/* Copyright (C) 2022 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, see + <https://www.gnu.org/licenses/>. */ + +#include "../strcpy.S"