From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57375 invoked by alias); 3 Mar 2020 02:03:02 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 57340 invoked by uid 89); 3 Mar 2020 02:03:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,KAM_INFOUSMEBIZ,MSGID_FROM_MTA_HEADER,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 spammy=H*RU:e400, HX-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:sk:0000000, HX-Spam-Relays-External:e400, quo X-HELO: NAM11-CO1-obe.outbound.protection.outlook.com Received: from mail-co1nam11olkn2028.outbound.protection.outlook.com (HELO NAM11-CO1-obe.outbound.protection.outlook.com) (40.92.18.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Mar 2020 02:02:59 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jUV9PwqvztnPHL1tBij+JAZeQbvi3pr5yw4myaLPwbzCuZDDbgxb0GNzvao2tZqUFuayhmYqog1Tc8YiD7gLOl1RWdnZXB4jU/VEy/gSNW/XoxXAHFHtGpPSsxJ6/l2YwpWn25DuPIT/1KM20bggSFKWVdIsmUXKMNrC8wn76FtaudWAgreuuIiH3BTfFrXnShDGxiDBN2foIhy0B73crlErUtEI5Oiqgru829IxI1uOg5QHVOYrAzCApGYdB2GvdwJ0JcAOPMoSiMnnnplYzJk2bpPilvMCAodWxY1Zi03oN55W49VGZk0Ujdhqhs57GlfWUD2NlrbAShaFV19z7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eNseNY1BjSQwPsLLUl24JDrwAVKbJNb/f2LufdF1LRM=; b=Ep6LsOBSVThmZNB0ovTFZmtsZtkzKKM3rtMktg6KbOG+ugiHjuzexLaEnY5Nm2as/L/C5rLXScimHMEw3LGpM/syOGAXyA9C8JmYZILWl+uo6qt6F41Dj/2ePXVAZpj5SESGe8HL8GZNB0Ch1CLL2ACeESAJZB46MDHvbIXjMratg3v6WKPi7eOtfl2alQ/nk05TduUy396vUug1pYs9CglNYOSAm5HrF+Y1l4hY+ib6zItw9TkwzjeXcWwVAVjKTQ8OSEtWdd20SjCWfxOOAFryQDuXUB9TlUx3hSOGM3mgmTKcEk2t2e7pUULerSRVzDfdZqtTXuNl7y+BST8MFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=maskray.me; dmarc=pass action=none header.from=maskray.me; dkim=pass header.d=maskray.me; arc=none Received: from CO1NAM11FT038.eop-nam11.prod.protection.outlook.com (2a01:111:e400:3861::3c) by CO1NAM11HT125.eop-nam11.prod.protection.outlook.com (2a01:111:e400:3861::122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Tue, 3 Mar 2020 02:02:56 +0000 Received: from BY5PR07MB7316.namprd07.prod.outlook.com (10.13.174.53) by CO1NAM11FT038.mail.protection.outlook.com (10.13.174.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14 via Frontend Transport; Tue, 3 Mar 2020 02:02:56 +0000 Received: from BY5PR07MB7316.namprd07.prod.outlook.com ([fe80::9dce:8d96:403c:b724]) by BY5PR07MB7316.namprd07.prod.outlook.com ([fe80::9dce:8d96:403c:b724%6]) with mapi id 15.20.2772.019; Tue, 3 Mar 2020 02:02:56 +0000 References: <20200302065602.jtyhq5wkhmz5kqh2@gmail.com> <20200302105939.GI5384@bubble.grove.modra.org> <20200302225028.GL5384@bubble.grove.modra.org> In-Reply-To: <20200302225028.GL5384@bubble.grove.modra.org> From: Fangrui Song Date: Tue, 03 Mar 2020 02:03:00 -0000 Message-ID: Subject: Re: [PowerPC] Garbage collecting .toc entries in a non-adhoc way (section group) To: Alan Modra Cc: binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" Return-Path: i@maskray.me X-Microsoft-Original-Message-ID: MIME-Version: 1.0 Received: from mail-qt1-f175.google.com (209.85.160.175) by MN2PR16CA0039.namprd16.prod.outlook.com (2603:10b6:208:234::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14 via Frontend Transport; Tue, 3 Mar 2020 02:02:54 +0000 Received: by mail-qt1-f175.google.com with SMTP id j23so1662145qtr.11 for ; Mon, 02 Mar 2020 18:02:54 -0800 (PST) X-Microsoft-Original-Message-ID: X-MS-Exchange-AntiSpam-MessageData: hDxiRy1VOh/3a5kiVF/67mJa6RE8kkPXBmtRvdV8XOuWzonnvkNsHM6pTb/4QuVHVQfzAB/20P33D9NEQ+5fBJSV9bD6UzCWvQ4xVNxiE3nlifUjbV/bW/V5W9bmt5O6xdtNkTMJqWloxcH3wSn2pw== X-SW-Source: 2020-03/txt/msg00032.txt On Mon, Mar 2, 2020 at 2:50 PM Alan Modra wrote: > > On Mon, Mar 02, 2020 at 10:02:43AM -0800, Fangrui Song wrote: > > On Mon, Mar 2, 2020 at 2:59 AM Alan Modra wrote: > > > > > > On Sun, Mar 01, 2020 at 10:56:02PM -0800, Fangrui Song wrote: > > > > Now I am thinking about whether we can produce .toc in section groups to obtain garbage collection ability for free. > > > > > > > > .text (not in a section group) references `foo` defined in .data.rel.ro.foo (in a section group) via .toc . > > > > ``` > > > > .text > > > > addis 3,2,.LC0@toc@ha > > > > > > > > .section .data.rel.ro.foo,"aGw",foo,comdat > > > > .globl foo > > > > foo: > > > > > > > > .section .toc,"aGw",@progbits,foo,comdat > > > > .LC0: > > > > .tc foo[TC],foo > > > > ``` > > > > > > > > When `.data.rel.ro.foo` and the `.toc` are discarded due to the section > > > > group rule, the relocation from `.text` to the `.toc` becomes dangling. > > > > > > Yes, that breaks the ELF gABI which says: "A symbol table entry with > > > STB_LOCAL binding that is defined relative to one of a group's > > > sections, and that is contained in a symbol table section that is not > > > part of the group, must be discarded if the group members are > > > discarded. References to this symbol table entry from outside the > > > group are not allowed." > > > > > > I think what you're trying to do is reinvent the GOT. There isn't any > > > reason why powerpc64 can't use a GOT and GOT relocations. > > > > Yes, there is inventing the GOT. But neither GCC nor clang produces > > foo@got@ha and foo@got@l pairs. Is there some hidden wisdom I am > > missing? > > Normally a section group contains related information that a compiler > generates for something, for example, a function. Comdat groups are > used for things like out-of-line definitions of inline functions where > only one copy of the function should be kept. You seem to be turning > this idea on its head, trying to generate groups for references *to* a > function. That quite obviously can't work in general, because all the > groups generated with a particular signature in a program should > contain the same information: Any one of the groups can be kept by > the linker. That means references to external functions can't be > placed in a group with the same signature as the function. For this case, foo may be a static function-local object in an inline function. The symbol foo is defined in .data.rel.ro.foo and all its references are via .toc Thus I imagined that in the absence of GOT-generating relocations (clang/GCC status quo), placing .toc in the same section group can deduplicate TOC entries. > So your scheme could only work for functions where you have a local > definition of the function. Which is surely not a huge percentage of > .toc addresses. And if you're making compiler changes, why not go all > the way and change gcc or clang to generate @got references? The > relocs are available, and BFD ld at least should handle them. Thanks for the confirmation that switching to @got may be beneficial. Is there any drawback? I spend very little of time contributing to LLVM's PowerPC backend. If you think @got is good, I'd like to investigate more. I have barely any GCC commit and I will likely not contribute there. > Incidentally, BFD ld edits the toc to remove unused entries Thanks for the confirmation. If compilers are generating TOC relocations, then such ad-hoc garbage collection is unavoidable.