Message ID | 20210609122916.3884385-1-hjl.tools@gmail.com |
---|---|
State | New |
Headers | show |
Series | Configure GCC with --enable-initfini-array [BZ #27945] | expand |
On Wed, 9 Jun 2021, H.J. Lu via Libc-alpha wrote: > Starting from GCC 12, the .init_array and .fini_array sections are enabled > unconditionally by > > commit 13a39886940331149173b25d6ebde0850668d8b9 > Author: H.J. Lu <hjl.tools@gmail.com> > Date: Tue Jun 8 16:09:24 2021 -0700 > > Always enable DT_INIT_ARRAY/DT_FINI_ARRAY on Linux > > configure GCC with --enable-initfini-array to enable them when using GCC > release branches. > > Fixes BZ #27945. The point of build-many-glibcs.py isn't to build a glibc that's in some sense optimal. This option isn't needed to get glibc to build, and it doesn't add to the diversity of configurations covered by build-many-glibcs.py (actually, it reduces that diversity by making the configurations built with older GCC versions more similar to those built with GCC 12). So I don't see adding this GCC configure option as within scope for build-many-glibcs.py.
On Wed, Jun 9, 2021 at 9:07 AM Joseph Myers <joseph@codesourcery.com> wrote: > > On Wed, 9 Jun 2021, H.J. Lu via Libc-alpha wrote: > > > Starting from GCC 12, the .init_array and .fini_array sections are enabled > > unconditionally by > > > > commit 13a39886940331149173b25d6ebde0850668d8b9 > > Author: H.J. Lu <hjl.tools@gmail.com> > > Date: Tue Jun 8 16:09:24 2021 -0700 > > > > Always enable DT_INIT_ARRAY/DT_FINI_ARRAY on Linux > > > > configure GCC with --enable-initfini-array to enable them when using GCC > > release branches. > > > > Fixes BZ #27945. > > The point of build-many-glibcs.py isn't to build a glibc that's in some > sense optimal. This option isn't needed to get glibc to build, and it > doesn't add to the diversity of configurations covered by > build-many-glibcs.py (actually, it reduces that diversity by making the > configurations built with older GCC versions more similar to those built > with GCC 12). So I don't see adding this GCC configure option as within > scope for build-many-glibcs.py. I disagree. The behavior of the cross compiler should be as close to the native Linux system compiler, not other versions of cross compilers, as possible. Can you tell me which native Linux system compilers don't support DT_INIT_ARRAY/DT_FINI_ARRAY?
On Wed, 9 Jun 2021, H.J. Lu via Libc-alpha wrote: > I disagree. The behavior of the cross compiler should be as close to the native > Linux system compiler, not other versions of cross compilers, as possible. But fixing that was the point of your GCC patch. I don't think working around deficiencies in previous versions of GCC, that aren't necessary to work around for building glibc, is within scope for build-many-glibcs.py; it's enough that the bug (cross compiler different from native) was fixed in the logically correct place (in GCC, for future GCC releases).
On 09/06/2021 15:02, Joseph Myers wrote: > On Wed, 9 Jun 2021, H.J. Lu via Libc-alpha wrote: > >> I disagree. The behavior of the cross compiler should be as close to the native >> Linux system compiler, not other versions of cross compilers, as possible. > > But fixing that was the point of your GCC patch. I don't think working > around deficiencies in previous versions of GCC, that aren't necessary to > work around for building glibc, is within scope for build-many-glibcs.py; > it's enough that the bug (cross compiler different from native) was fixed > in the logically correct place (in GCC, for future GCC releases). But this also does not have any really drawback, correct? I thinking for the possible support to add a way to build a specific gcc/binutins/glibc version with build-many-glibcs.py.
On Wed, Jun 9, 2021 at 11:13 AM Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> wrote: > > > > On 09/06/2021 15:02, Joseph Myers wrote: > > On Wed, 9 Jun 2021, H.J. Lu via Libc-alpha wrote: > > > >> I disagree. The behavior of the cross compiler should be as close to the native > >> Linux system compiler, not other versions of cross compilers, as possible. > > > > But fixing that was the point of your GCC patch. I don't think working > > around deficiencies in previous versions of GCC, that aren't necessary to > > work around for building glibc, is within scope for build-many-glibcs.py; > > it's enough that the bug (cross compiler different from native) was fixed > > in the logically correct place (in GCC, for future GCC releases). > > But this also does not have any really drawback, correct? > > I thinking for the possible support to add a way to build a specific > gcc/binutins/glibc version with build-many-glibcs.py. See: https://gitlab.com/hjl.tools/x86-64-linux-toolchain
On Wed, 9 Jun 2021, Adhemerval Zanella via Libc-alpha wrote: > On 09/06/2021 15:02, Joseph Myers wrote: > > On Wed, 9 Jun 2021, H.J. Lu via Libc-alpha wrote: > > > >> I disagree. The behavior of the cross compiler should be as close to the native > >> Linux system compiler, not other versions of cross compilers, as possible. > > > > But fixing that was the point of your GCC patch. I don't think working > > around deficiencies in previous versions of GCC, that aren't necessary to > > work around for building glibc, is within scope for build-many-glibcs.py; > > it's enough that the bug (cross compiler different from native) was fixed > > in the logically correct place (in GCC, for future GCC releases). > > But this also does not have any really drawback, correct? It's one more thing to track when to remove when the minimum GCC version for building glibc increases. (We have such a comment on the use of --disable-libcilkrts. We ought to have one on the use of --disable-libmpx. If we used --enable-initfini-array, that should have such a comment as well.)
On Wed, 9 Jun 2021, H.J. Lu via Libc-alpha wrote: > See: > > https://gitlab.com/hjl.tools/x86-64-linux-toolchain That looks like it has different scope and goals from build-many-glibcs.py. As another example, build-many-glibcs.py doesn't build GCC with ISL - because that's not relevant to testing different glibc configurations, so adding ISL to the build would just add extra irrelevant complications. As another example closer to the present case, you're using --enable-gnu-indirect-function. That option can definitely be relevant to the glibc build - but we also want glibc to be able to build with GCC versions not defaulting to enabling that option on all relevant architectures, and adding that option in build-many-glibcs.py on relevant architectures would both reduce test coverage and lead to extra duplicated knowledge in build-many-glibcs.py about which architectures that option is relevant on.
On 09/06/2021 17:44, Joseph Myers wrote: > On Wed, 9 Jun 2021, Adhemerval Zanella via Libc-alpha wrote: > >> On 09/06/2021 15:02, Joseph Myers wrote: >>> On Wed, 9 Jun 2021, H.J. Lu via Libc-alpha wrote: >>> >>>> I disagree. The behavior of the cross compiler should be as close to the native >>>> Linux system compiler, not other versions of cross compilers, as possible. >>> >>> But fixing that was the point of your GCC patch. I don't think working >>> around deficiencies in previous versions of GCC, that aren't necessary to >>> work around for building glibc, is within scope for build-many-glibcs.py; >>> it's enough that the bug (cross compiler different from native) was fixed >>> in the logically correct place (in GCC, for future GCC releases). >> >> But this also does not have any really drawback, correct? > > It's one more thing to track when to remove when the minimum GCC version > for building glibc increases. (We have such a comment on the use of > --disable-libcilkrts. We ought to have one on the use of > --disable-libmpx. If we used --enable-initfini-array, that should have > such a comment as well.) > So I stumbled across this issues while testing powerpc64le with the build-many-glibcs built gcc with lld, which does not support .ctors (it just ignores the sections instead of converting it on .init_array). I agree with H.J that is unfortunate that gcc has the issue and although it does not prevent to work against ld.bfd, it might prevent glibc to be built properly with other linkers. So I think it would be good to have such patch upstream with.
On Fri, Nov 5, 2021 at 12:45 PM Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote: > > > > On 09/06/2021 17:44, Joseph Myers wrote: > > On Wed, 9 Jun 2021, Adhemerval Zanella via Libc-alpha wrote: > > > >> On 09/06/2021 15:02, Joseph Myers wrote: > >>> On Wed, 9 Jun 2021, H.J. Lu via Libc-alpha wrote: > >>> > >>>> I disagree. The behavior of the cross compiler should be as close to the native > >>>> Linux system compiler, not other versions of cross compilers, as possible. > >>> > >>> But fixing that was the point of your GCC patch. I don't think working > >>> around deficiencies in previous versions of GCC, that aren't necessary to > >>> work around for building glibc, is within scope for build-many-glibcs.py; > >>> it's enough that the bug (cross compiler different from native) was fixed > >>> in the logically correct place (in GCC, for future GCC releases). > >> > >> But this also does not have any really drawback, correct? > > > > It's one more thing to track when to remove when the minimum GCC version > > for building glibc increases. (We have such a comment on the use of > > --disable-libcilkrts. We ought to have one on the use of > > --disable-libmpx. If we used --enable-initfini-array, that should have > > such a comment as well.) > > > > So I stumbled across this issues while testing powerpc64le with the > build-many-glibcs built gcc with lld, which does not support .ctors > (it just ignores the sections instead of converting it on .init_array). > > I agree with H.J that is unfortunate that gcc has the issue and > although it does not prevent to work against ld.bfd, it might prevent > glibc to be built properly with other linkers. > > So I think it would be good to have such patch upstream with. I am checking in this patch now. Thanks.
On Fri, 5 Nov 2021, H.J. Lu wrote: > I am checking in this patch now. Please see my previous comment. If adding such a configure option that won't be needed with future GCC versions, you also need to add a comment saying what GCC version makes that option no longer required. > > > It's one more thing to track when to remove when the minimum GCC version > > > for building glibc increases. (We have such a comment on the use of > > > --disable-libcilkrts. We ought to have one on the use of > > > --disable-libmpx. If we used --enable-initfini-array, that should have > > > such a comment as well.)
On Mon, Nov 8, 2021 at 7:01 AM Joseph Myers <joseph@codesourcery.com> wrote: > > On Fri, 5 Nov 2021, H.J. Lu wrote: > > > I am checking in this patch now. > > Please see my previous comment. If adding such a configure option that > won't be needed with future GCC versions, you also need to add a comment > saying what GCC version makes that option no longer required. https://sourceware.org/pipermail/libc-alpha/2021-November/132797.html > > > > It's one more thing to track when to remove when the minimum GCC version > > > > for building glibc increases. (We have such a comment on the use of > > > > --disable-libcilkrts. We ought to have one on the use of > > > > --disable-libmpx. If we used --enable-initfini-array, that should have > > > > such a comment as well.) > > -- > Joseph S. Myers > joseph@codesourcery.com
diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py index 4a4b91abda..5ce86c96d0 100755 --- a/scripts/build-many-glibcs.py +++ b/scripts/build-many-glibcs.py @@ -1437,6 +1437,7 @@ class Config(object): # removed once glibc no longer supports building with older # GCC versions). cfg_opts = list(self.gcc_cfg) + cfg_opts += ['--enable-initfini-array'] cfg_opts += ['--disable-libssp', '--disable-libcilkrts'] host_libs = self.ctx.host_libraries_installdir cfg_opts += ['--with-gmp=%s' % host_libs,