diff mbox series

Configure GCC with --enable-initfini-array [BZ #27945]

Message ID 20210609122916.3884385-1-hjl.tools@gmail.com
State Committed
Commit a586fe9c80f7cf2c9a5a6ccdbc572e7b5ec816b8
Headers
Series Configure GCC with --enable-initfini-array [BZ #27945] |

Checks

Context Check Description
dj/TryBot-apply_patch success Patch applied to master at the time it was sent

Commit Message

H.J. Lu June 9, 2021, 12:29 p.m. UTC 
  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.
---
 scripts/build-many-glibcs.py | 1 +
 1 file changed, 1 insertion(+)

Comments

Joseph Myers June 9, 2021, 4:07 p.m. UTC | #1 
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.
H.J. Lu June 9, 2021, 5:46 p.m. UTC | #2 
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?
Joseph Myers June 9, 2021, 6:02 p.m. UTC | #3 
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).
Adhemerval Zanella June 9, 2021, 6:13 p.m. UTC | #4 
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.
H.J. Lu June 9, 2021, 7:01 p.m. UTC | #5 
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
Joseph Myers June 9, 2021, 8:44 p.m. UTC | #6 
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.)
Joseph Myers June 9, 2021, 8:52 p.m. UTC | #7 
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.
Adhemerval Zanella Nov. 5, 2021, 7:45 p.m. UTC | #8 
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.
H.J. Lu Nov. 5, 2021, 10:09 p.m. UTC | #9 
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.
Joseph Myers Nov. 8, 2021, 3:01 p.m. UTC | #10 
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.)
H.J. Lu Nov. 8, 2021, 3:51 p.m. UTC | #11 
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 mbox series

Patch

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,