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_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 7F16B1F4B5 for ; Tue, 12 Nov 2019 20:59:58 +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=s0heVkbJhIFlOOEM 9L0auokGitD8NY30TreGbmBZ7Zh+zhPDeng8EprPY9Ug6P8tIei39z+x2HXiEBIa 7kxbUNw4wXQvnmmY3LH8DULJWOlFFLDkHr76fw6CLxzJ+dROJXskitiIbdrgKWaX E8JEAmnva2ftRvCvkMY19gS+RQs= 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=8AE63L2yEDjrhdUCL3BYIB NtuaY=; b=wzY9H055ukCz9on3b8jND54P5a0WGG/zIuiac23akaQq/zlNxIMUQf y3ZdDA6Z7+4QUtV2QNR9V2Fd4hZ2yk8XGvxt8t/Y9WDS9Xlsp/r+bwsWv9gJzPmj edYXlpWBrt4Z+Ty78Tp571H9tFFwduKOSSAh50gE+KHtY2S+FZRbc= Received: (qmail 56428 invoked by alias); 12 Nov 2019 20:59:56 -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 56418 invoked by uid 89); 12 Nov 2019 20:59:56 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: esa4.mentor.iphmx.com IronPort-SDR: WvIirwm7c9p2xVf0lfvDM64DbXAKKUiW/RCsBCr/OgPC6fYdzIP/uBavEFyD4ADTsX3KCsmn/i Xc8XLX9MlRVVbPXwR2b8kag5t5mnfvznT4XOGiWM+gCuGcMMVSK9y/nqtn34bd3T4FnaXIkOzJ CR8xVUN3nu5aycNUVbszowe4OwjtRPagcRI8CSJGCg8CgBCRGtKccQniAnKtNhQICcSbCxc1I1 y+boREtzzvQWpJJqIl8bcTioNatM6/BVSqP3vpfbYrbNc8A8kso8lWvQHs8HJDYPYhcrzNt5HD xws= IronPort-SDR: JIdhfYWWnjGp2QJ/RSt07WqXllEkFaDqVxrIOMiDbJTASrxWMrxJrekosaskgSQRZ6T/f59CYo R9JCGkk2IcJudmT9yt1a7OlADpfnh150RjZ44RtxXx6qJfThJ6z5wEdA3GN1Ue0KVxNU3WCMic TYGn0UGBjI41cYzdz/+4XCvYOMI2tBwgUOwh17uLTNvqFBZcrknB9lsuCZGBX9UtgJa0zrosNl aXBDF1XCLOEKC9NOEZCOjICJAm85Hdgoou9/SCyrkkgbZsF9X5kl9z2v7gI9B5FLW/bbA40UlM W0s= Subject: Re: [review v3] slotinfo in struct dtv_slotinfo_list should be flexible array [BZ #25... To: Florian Weimer CC: Joseph Myers , Florian Weimer , , Szabolcs Nagy , , References: <20191112114732.2175B20AF6@gnutoolchain-gerrit.osci.io> <4e7ad8ea-43ae-6af6-d2a9-2a05d42b0cc6@codesourcery.com> <87r22dey2c.fsf@mid.deneb.enyo.de> From: Sandra Loosemore Message-ID: <55541dd4-7e5e-e7ec-ae17-e9904041780e@codesourcery.com> Date: Tue, 12 Nov 2019 13:59:47 -0700 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> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 11/12/19 11:42 AM, Florian Weimer wrote: > * Sandra Loosemore: > >> I don't have any state on this particular change or what it is trying to >> accomplish, but the linker error is the sort of thing that happens when >> the compiler sees a reference to an object it thinks will be put in the >> small data section, but the actual definition of the object puts it >> somewhere else (e.g., because it is too big for small data) -- in this >> case the .bss section. Are there conflicting declarations about the >> size of the object? If that's unavoidable for some reason, another way >> to suppress GP-relative addressing on this object would be to give it an >> explicit .bss section attribute everywhere it's declared. > > Thanks for providing this information. Here is a small reproducer: > > enum { size = 100 }; > > struct flexible > { > int length; > int data[]; > }; > > struct inflexible > { > int length; > int data[size]; > }; > > static struct flexible flexible = > { > .data = { [size - 1] = 0, } > }; > > static struct inflexible inflexible = > { > .data = { [size - 1] = 0, } > }; > > struct flexible * > get_flexible (void) > { > return &flexible; > } > > struct inflexible * > get_inflexible (void) > { > return &inflexible; > } > > It results in: > > .file "t.c" > .section .text > .align 2 > .global get_flexible > .type get_flexible, @function > get_flexible: > addi r2, gp, %gprel(flexible) > ret > .size get_flexible, .-get_flexible > .align 2 > .global get_inflexible > .type get_inflexible, @function > get_inflexible: > movhi r2, %hiadj(inflexible) > addi r2, r2, %lo(inflexible) > ret > .size get_inflexible, .-get_inflexible > .section .bss > .type inflexible, @object > .size inflexible, 404 > .align 2 > inflexible: > .zero 404 > .type flexible, @object > .size flexible, 404 > .align 2 > flexible: > .zero 404 > .ident "GCC: (GNU) 9.2.1 20191101 [gcc-9-branch revision 277712]" > > 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. > > 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). > > 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. > > 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. > OK, having a self-contained test case is very helpful. I'll take a look at fixing this in GCC, although I might not get to it for a few days. Probably the solution is to not use GP-relative addressing for any object declared with a flexible array member. -Sandra