From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) by sourceware.org (Postfix) with ESMTPS id 856E83857C46 for ; Wed, 23 Sep 2020 13:40:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 856E83857C46 Received: by mail-io1-xd43.google.com with SMTP id r25so23754809ioj.0 for ; Wed, 23 Sep 2020 06:40:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Kw6KuLZwYWhSyrrVtQIiqgHrDKC8jiMf6yNvGcSPQQo=; b=c2+v8uk+75oWT8GQrFtSBoiuiSwT+1J4sKtXuz0wFwuLzsi/B/jUVtBAzU24ztOa/k F+knwMjFBiMjwbU8y214ZV0ZkPvPtYcryvTLQvOtroEd5d11riJ5tR0yv0I98mJmTwIF BgN4lXyp9X+HXd3q7q2Xg9+FAZQe+pkidHG/SSONYQdEZOS2bLKlI00HDlKDdpeDStbp 1iUvnmmk/XIu53DLKQamOL7ZQ2wT5vHd3P5+U+TDE1MKmgJ4lLWxnN9/DotnojGGQwue yHduK8gxNUglRRQJkCCrXldqn5ODGC0yvW0kgFXyO3R0SCumF4Da/3N0bgtM1D1185u5 2cXw== X-Gm-Message-State: AOAM533j84pOyQmuHgBnOoTmQvcZQq5K/ERwf1gbJV9SoAxCrxs0R/Ta cgwpgee0qC5+Epi+umB+RjWOUGyimuDbbxdVVAM= X-Google-Smtp-Source: ABdhPJzkdk+PbrAVLD0WSlepP114kYw85Szmh1dO41pzoYVc02P31ulQgOQS6N/LNuX2td6bZuFN8aO5yHmeGsLbITc= X-Received: by 2002:a5e:9e4c:: with SMTP id j12mr7372297ioq.37.1600868400975; Wed, 23 Sep 2020 06:40:00 -0700 (PDT) MIME-Version: 1.0 References: <20200923010930.xtc4mgmxsoesohkn@gmail.com> <20200923095818.npbwybrm63vb4ejm@jozef-acer-manjaro> In-Reply-To: <20200923095818.npbwybrm63vb4ejm@jozef-acer-manjaro> From: "H.J. Lu" Date: Wed, 23 Sep 2020 06:39:25 -0700 Message-ID: Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag To: Hans-Peter Nilsson , "H.J. Lu" , Fangrui Song , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.3 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 13:40:02 -0000 On Wed, Sep 23, 2020 at 2:58 AM Jozef Lawrynowicz wrote: > > On Tue, Sep 22, 2020 at 07:24:01PM -0400, Hans-Peter Nilsson wrote: > > On Tue, 22 Sep 2020, Jozef Lawrynowicz wrote: > > > The new tests are passing for all targets except mmix-elf. > > > > There is no mmix-elf target: if it's buildable, that's a > > mistake. I'm not sure what kind of abomination results, if it's > > a goldblum-fly or karloff-frankensteins. :) > > > > The target mmix a.k.a. mmix-knuth-mmixware assembles to ELF, but > > links to MMO by use of the generic linker machinery. You *can* > > link to ELF by means of the linker option "-m elf64mmix". > > > > brgds, H-P > > > > Ah, thanks for the info. I formed that list of targets by just > extracting the CPU name from all the files in bfd/ with "elf" in the > name. > > mmix-elf is buildable, and most tests pass, but it definitely appears > that a lot is broken! > > ==> mmix-elf/binutils.sum <== > # of expected passes 122 > # of unexpected failures 38 > ==> mmix-elf/gas.sum <== > # of expected passes 446 > # of unexpected failures 68 > ==> mmix-elf/ld.sum <== > # of expected passes 430 > # of unexpected failures 158 > > I'll remove any mmix-elf-specific XFAIL-ing from the patch. > > On Tue, Sep 22, 2020 at 04:58:23PM -0700, H.J. Lu via Binutils wrote: > > On Tue, Sep 22, 2020 at 1:30 PM Jozef Lawrynowicz > > wrote: > > > > > + /* A GNU extension for preventing linker garbage collection of sections. */ > > + {"retain", obj_elf_retain, 0}, > > + > > > > Why is this needed? Isn't > > > > @@ -857,6 +861,9 @@ obj_elf_parse_section_letters (char *str, size_t len, > > case 'd': > > *gnu_attr |= SHF_GNU_MBIND; > > break; > > + case 'R': > > + *gnu_attr |= SHF_GNU_RETAIN; > > + break; > > case '?': > > *is_clone = TRUE; > > break; > > > > enough? The .section directive is used for all other SHF_XXX bits. I don't > > think we need a separate directive for SHF_GNU_RETAIN? > > GCC doesn't know if SHF_GNU_RETAIN is required when creating a section, > since the "retain" attribute is applied to function and data > declarations. > > So rather than emitting the section directive again, which could be > confusing if there are two almost identical section declarations, the > ".retain" directive describes the precise augmentation to make to the > already-declared section. > > I think that: > > > .section .text,"ax" > > ... > > foo: > > ... > > .retain > > retained_fn: > > ... > > is some nice syntactic sugar compared to: > > > .section .text,"ax" > > ... > > foo: > > ... > > .section .text,"axR" > > retained_fn: > > ... > > It's also partly for convenience; we have other directives which are > synonyms or short-hand for each other. > You don't need to keep the whole section when only one symbol should be kept. Please drop the .retain directive. GCC, as and ld should do the right thing with .section .text,"ax" ... foo: ... .section .text,"axR" retained_fn: where foo can be dropped and retained_fn will be kept. H.J.