From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id 1152B3858407 for ; Tue, 29 Nov 2022 12:22:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1152B3858407 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x633.google.com with SMTP id d6so13222484pll.7 for ; Tue, 29 Nov 2022 04:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=IU+iYMqcIYcl+BCjyGgrT9GZmDcOgd6R3MSgx+nyrMM=; b=SEfS+kkhKQx6q+yp3kV8E7MYhGisCQ+kfh3EC5y5ikVPb7bHm4bVf497fZR9BeI0Dh ZZKHfLjh2PQGnmabWwGZrN6fyh3NotTc4HhkC0zpUU6k1q2fpKoH0b3eCqZxeZtRwJMy UGnfd+NRsHw4dUrWsQ+dmuZkOPCdCWIRxrRAr6GwoTKhcZ6phIRZDbBx3ZKMr49vUOmM i8SiE/4WKf4yHHM9BpmROMtNbVIwf5nuHXA+EDXhXDQLm+RFTu+ZpJJTP6J/8h3NYO/y QZ3/lUS9p0V2qI5gPAvIGwbK+jlJxz637xd6oZ4Sr/GtfjZqYfYTYpvrL8WgpjaOWis1 /7fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IU+iYMqcIYcl+BCjyGgrT9GZmDcOgd6R3MSgx+nyrMM=; b=0+6+77WPYjiOYcT/IuzyomRbU2q2vXN+9kLIxGY9XmoWN7Tf7PZWn6wEh7Zr8NKJqw iTvH6HK3vwZpHWDsBkhEnQr25KS7g/jTdryd+lJLwzZSC+yQsKlBhE4mPctGJCr/JeW7 YKcVzMbAV76rDemAqLl2ASeUfy27GQeJHk4NBXB4IukjUVTmvuWSWUxpaObX6054RyEK 3icqyhC2sfGpX+K0lmu5TqaWasubve6cZNU+7yrd55UPHo1R/7gTeVWoRM2p12omDAX4 ye7h/OC2djaUHTNQgPkyKiv96qGEOBzeuSyDhJRkRzXdsbzJrv+04+pdiGymdWkhkA/B Ja9Q== X-Gm-Message-State: ANoB5pl9ME489jzUboLapOe1oMP9kDVliMLHvnz2WI0XnsAfM5msfcqD i3htu806elESxeau5Wp+RvCgLvSCKts= X-Google-Smtp-Source: AA0mqf4TJSGvAPvhdTscyNdgKJSHXIjhWPRuwLV0StLq1LUmG/MJY7BOc2J1yGn0SJQVxnebv11jhw== X-Received: by 2002:a17:90a:880f:b0:212:e996:704a with SMTP id s15-20020a17090a880f00b00212e996704amr63845643pjn.13.1669724541462; Tue, 29 Nov 2022 04:22:21 -0800 (PST) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:399c:e42a:7abd:9618]) by smtp.gmail.com with ESMTPSA id w9-20020a170902904900b00187033cac81sm10728709plz.145.2022.11.29.04.22.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Nov 2022 04:22:20 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id E537D1142D4E; Tue, 29 Nov 2022 22:52:17 +1030 (ACDT) Date: Tue, 29 Nov 2022 22:52:17 +1030 From: Alan Modra To: Michael Matz Cc: binutils@sourceware.org Subject: Re: [PATCH 4/8] section-select: Completely rebuild matches Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3028.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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 List-Id: On Mon, Nov 28, 2022 at 02:24:30PM +0000, Michael Matz wrote: > Hello, > > On Mon, 28 Nov 2022, Alan Modra wrote: > > > On Fri, Nov 25, 2022 at 04:55:12PM +0000, Michael Matz via Binutils wrote: > > > this resets all section matches before updating for newly created > > > sections (i.e. completely rebuilds the matches). This fixes powerpc > > > "TOC opt" tests that shows a difference in section order: originally > > > .got of "linker stubs" comes before .toc (both placed into the same > > > .got output section due to ".got {*(.got .toc)}". But .got of linker > > > stubs is created later, and in the second run of resolve_wilds is > > > appended to the list, hence is then coming after .toc (which was added > > > already in the earlier resolve_wilds run). So order swapped -> > > > test fails. > > > > That's a problem. The got header is created in the .got of "linker > > stubs", and code setting the value of .TOC. assumes that the header > > will be located first in the .got output section. This ties in with > > where ld.so expects to find the header too. > > I see. But then why is the testcase (and linker script?) not using > > .got { *(.got) *(.toc) } > > ? The way it's written right now means "for each file, first its .got > then its .toc, intermixed", i.e. file1.got, file1.toc, file2.got, > file2.toc ... Yes. That's the way we want it. When linking small model code with a total GOT/TOC of over 64k, the linker splits the TOC into multiple pieces with r2 adjusting stubs inserted on calls between files that use different pieces of the TOC. That scheme wouldn't work if a file's .got entries were placed in a different piece of the TOC to the file's .toc entries. -- Alan Modra Australia Development Lab, IBM