From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id F12421F4B5 for ; Tue, 12 Nov 2019 22:14:59 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=p1JdEkYb7dndG65F sVWaZjmoVY0+5nI4P8K0slvgfnAuM9qf6KE4VQfQoXKFz9G2GtnQJ57nG0Syogqo EYq8Dr+7nzOJscqhQA0upF/4kPYt/o/cllXdoB4mKA1Ls0Dup3MuDp1+oP8EMx/E eKLS85PtS1QRQU5093NhK1NQFnE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=6Jaesv0CiYZJOXrLBtPNnx xWD5c=; b=OwKtgdmGgCGfWXFKHhMTnNvPV9ao9q4HgMxcZG0+ARYz0bmYPNpMFF In6pDy3tp9mbaeWvZlOLmnrUA8BUUy+dqWgod2gBqpiay8xL2ep/cWUDdDenx1D2 mrmUm08ZUFUqmUWbuASAl0jisX2MwzS/fL4t7v1wPnqENJLsIYML4= Received: (qmail 35509 invoked by alias); 12 Nov 2019 22:14:57 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 35499 invoked by uid 89); 12 Nov 2019 22:14:57 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573596894; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hODpsa/waWSGDk/lFcZAO4B2mJ1rdLx3UR0XPvdpUOg=; b=IgJOu8uwbsQIXJ5OU2SVW8EByhciFz+twiNIg6hEzpaz5er+FcgIr1koGmPXVJ1zHjGqMS JAE00QbXjFVxkBzWyqjMorOXROFCeyFCv4PU6A8YsVhU+BHa2zkR2J86ysVRYkPe0oUEWl 2vRykEDxmDcZstBmWLbIALCP20Jnvb4= Subject: Re: [review v3] slotinfo in struct dtv_slotinfo_list should be flexible array [BZ #25... To: Florian Weimer , Sandra Loosemore Cc: Joseph Myers , Florian Weimer , libc-alpha@sourceware.org, Szabolcs Nagy , cltang@codesourcery.com, andrew@codesourcery.com References: <20191112114732.2175B20AF6@gnutoolchain-gerrit.osci.io> <4e7ad8ea-43ae-6af6-d2a9-2a05d42b0cc6@codesourcery.com> <87r22dey2c.fsf@mid.deneb.enyo.de> From: Carlos O'Donell Message-ID: <320362b6-854f-230e-5db8-af20f66ef838@redhat.com> Date: Tue, 12 Nov 2019 17:14:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <87r22dey2c.fsf@mid.deneb.enyo.de> X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable On 11/12/19 1:42 PM, Florian Weimer wrote: > * Sandra Loosemore: >=20 >> I don't have any state on this particular change or what it is trying to= =20 >> accomplish, but the linker error is the sort of thing that happens when= =20 >> the compiler sees a reference to an object it thinks will be put in the= =20 >> small data section, but the actual definition of the object puts it=20 >> somewhere else (e.g., because it is too big for small data) -- in this= =20 >> case the .bss section. Are there conflicting declarations about the=20 >> size of the object? If that's unavoidable for some reason, another way= =20 >> to suppress GP-relative addressing on this object would be to give it an= =20 >> explicit .bss section attribute everywhere it's declared. >=20 > Thanks for providing this information. Here is a small reproducer: >=20 > enum { size =3D 100 }; >=20 > struct flexible > { > int length; > int data[]; > }; >=20 > struct inflexible > { > int length; > int data[size]; > }; >=20 > static struct flexible flexible =3D > { > .data =3D { [size - 1] =3D 0, } > }; >=20 > static struct inflexible inflexible =3D > { > .data =3D { [size - 1] =3D 0, } > }; >=20 > struct flexible * > get_flexible (void) > { > return &flexible; > } >=20 > struct inflexible * > get_inflexible (void) > { > return &inflexible; > } >=20 > It results in: >=20 > =09.file=09"t.c" > =09.section=09.text > =09.align=092 > =09.global=09get_flexible > =09.type=09get_flexible, @function > get_flexible: > =09addi=09r2, gp, %gprel(flexible) > =09ret > =09.size=09get_flexible, .-get_flexible > =09.align=092 > =09.global=09get_inflexible > =09.type=09get_inflexible, @function > get_inflexible: > =09movhi=09r2, %hiadj(inflexible) > =09addi=09r2, r2, %lo(inflexible) > =09ret > =09.size=09get_inflexible, .-get_inflexible > =09.section=09.bss > =09.type=09inflexible, @object > =09.size=09inflexible, 404 > =09.align=092 > inflexible: > =09.zero=09404 > =09.type=09flexible, @object > =09.size=09flexible, 404 > =09.align=092 > flexible: > =09.zero=09404 > =09.ident=09"GCC: (GNU) 9.2.1 20191101 [gcc-9-branch revision 277712]" >=20 > I think this shows that the backend uses the static type size (as in > sizeof) to determine whether an object goes into the small data > section, not the allocated object size. >=20 > The linker only sees the allocated object size, so it places the > object wrongly (although it could perhaps do something smarter because > it can see the relocations). >=20 > If the object is not placed into .bss, the choice of .sdata vs .data > is also based on the static type size, so that would need fixing too. >=20 > I don't know how to work around that in the source code. My > preference would be to fix the backend. I guess we could back out the > commit and disable the warning for GCC 10 instead. =20 If the new glibc cannot be compiled with gcc8 or gcc9 for nios2, then that'= s a problem though. It immediately makes it difficult to test a new glibc on existing systems without upgrading the system compiler. If there is a backend bug then it absolutely needs to be fixed, and it look= s like Sandra will try that, but that won't reach the affected compilers unti= l much much later. I dislike backing out the changes you made because they are quite nice cleanups, and the downstream vendors tend to upgrade glibc and gcc and binu= tils all in one big group to avoid these issues so I don't expect they will ever see this problem. It's only us as developers that see the larger version skew problem. My inclination is to fix the gcc problem, backport the solution to the acti= ve FSF branches, and then that fixes our testers. In order of importance: - Fix all gcc10 issues. - Fix the nios2 backend issue. - Backport nios2 backend to active FSF branches. - Rebuild and test to make sure we are all clean again. How long will that take and is it OK to leave things in a broken state for = that long for a given target like nios2? --=20 Cheers, Carlos.