From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by sourceware.org (Postfix) with ESMTPS id 8C9C23857C4C for ; Wed, 23 Sep 2020 09:58:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8C9C23857C4C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=mittosystems.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jozef.l@mittosystems.com Received: by mail-wr1-x442.google.com with SMTP id o5so20278779wrn.13 for ; Wed, 23 Sep 2020 02:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mittosystems.com; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:mime-version :content-disposition:in-reply-to; bh=/STwxTlJAXB1z8wnJx9aeqERMfAcbb6BgRfArfLhavc=; b=VbJcJ78+dD47ClubQeJRpB5gEx6uMQiXDQ/J3J3Yk+GiYa4m1huijW2eAiUWQVRBpz TZBiVHTJRtHdk/NoJWEWpw8td5UXdAY7bZ8/ZzFMs6McmXNv2KK0+shhF8XJs1E/vA6W yu2waKN2LRRcqUlsqI6U4SwWCoZ6iFBDXsz7UKxOqSBsHidGQ67vwkq3rdy4lkOrpf6c bt98xosA2cKE+DbSYMN/iyAwUPVFT/bCKES4Sz9TnUhvtVgtYec0FbCZCo5xrSFVrl/q lLhxvg4dCz862owKEJ+IHOTZ2wZjrbeKpbs+I/ThXPeH1z8me0jbzY6jkSkBRSziu9a6 D4zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:mime-version:content-disposition:in-reply-to; bh=/STwxTlJAXB1z8wnJx9aeqERMfAcbb6BgRfArfLhavc=; b=b3hi4ECzZAaSV9lIFAsy0WsaER9JDm2+Lzgt+HpjlUSPWNXUyRflIodb3W3Zti4ANh DK82wDnTv1BBmWm12sU6oXtRS7ivSW0In0w4WVOZeC9dnalcF3ryqFgPgiiotTldn+Xx jAF/9+rm5hGD5yRJxhlQ+oDyQBuLN4cn9FSJ38JLBgEZTH3unwOD5RP2qnVZ5USScFYY 1oGd6e1iZ1wF0OuFUlxYeHb3BMVJPd/JyYFUMeJVLX8EUS7Xm7rezrNt0o3x+c+WfMrd pimQk68MAn06dtl8rrij6P8Fp6Olo1ztTFZABvtm4s7fHAYR3/cHarWAJSXvq4/R20E+ HVjg== X-Gm-Message-State: AOAM530bOb+CN3Eu/ofx51Bp8WjENyG/2pl9xDoAoW4LdlimQaxzKuYd jtuLj1R60rQPDLa2IFENANhp+HrkcnGvTg== X-Google-Smtp-Source: ABdhPJzFkKWXr1foGHkjzu234/CfhWAGaLYY2TeO4IeMKNRF9Ftz62LSNLWT7aduueLPD1nGKMxnGQ== X-Received: by 2002:a5d:46c5:: with SMTP id g5mr10570620wrs.416.1600855102517; Wed, 23 Sep 2020 02:58:22 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id t4sm29911506wrr.26.2020.09.23.02.58.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2020 02:58:20 -0700 (PDT) Date: Wed, 23 Sep 2020 10:58:18 +0100 From: Jozef Lawrynowicz To: Hans-Peter Nilsson , "H.J. Lu" , Fangrui Song Cc: binutils@sourceware.org Subject: Re: [PATCH] Support SHF_GNU_RETAIN ELF section flag Message-ID: <20200923095818.npbwybrm63vb4ejm@jozef-acer-manjaro> Mail-Followup-To: Hans-Peter Nilsson , "H.J. Lu" , Fangrui Song , binutils@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200923010930.xtc4mgmxsoesohkn@gmail.com> X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 09:58:25 -0000 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. There's a bug in my patch where a .section directive without the "R" flag overrides an earlier .section directive for the same section with the "R" flag and clobbers SHF_GNU_RETAIN, I need to fix that. On Tue, Sep 22, 2020 at 06:09:30PM -0700, Fangrui Song wrote: > On 2020-09-22, Jozef Lawrynowicz wrote: > > The attached patch adds support for the new SHF_GNU_RETAIN ELF section > > flag, which was discussed on the GNU gABI mailing list here: > > https://sourceware.org/pipermail/gnu-gabi/2020q3/000429.html > > > > The flag is GNU-specific so uses a bit in the SHF_MASKOS mask. > > Its precise definition is as follows: > > We already have a way to create an artificial reference: > > .reloc ., R_X86_64_NONE, target_symbol > > If we allow a relocation number for the second operand > > .reloc ., 0, target_symbol > > this will be generic. You can insert the directives in a GC root (e.g. > _start or a symbol referenced by -u or maybe an .init_array) I don't really understand how this would work in most cases when the compiler or assembler aren't building the file which will contain the eventual GC root. How are they to know what the GC root is anyway? What if the assumed GC root changes after the files are built? I also don't see any advantage of re-purposing .reloc for this use case, over having a precisely defined new section flag. You would also have to look at relocations defined in the GC root function (mixed with relocations used for other purposes) to work out which sections are being retained, instead of having retention being a property of the section itself. Thanks, Jozef