From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id 17AA23857C46 for ; Fri, 18 Sep 2020 12:23:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 17AA23857C46 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-wm1-x332.google.com with SMTP id l15so6586539wmh.1 for ; Fri, 18 Sep 2020 05:23:00 -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:references:mime-version :content-disposition:in-reply-to; bh=L3aQVmr3+G9IWrTH19z8a6mfU795FTG69R+rOcqJisg=; b=l7ePOLOL4vkDLPIQ3MksBMs0Fa+YJfQs2YbyQvR/w1VXg5TfGnALzJj0zOGFXS4441 RG8khTtJIhp1JtwwwG4SP80d/gA/1PaEfO5AqeRiWRHBoz8dzENokTdn8VwWfnHzl2D8 OKZq5NVRxRvbhNAF8Io+MdpAH3og2veOhZriLOMuUi/jrKfyjcKlUpJOQiPx2pViChVk 6vdgObzIl2KRNlxjylG/oTotlrDjDCPeBpSuWH9S5GbtguFnKJTcGys9tLrJDrc4WoKG wWIVqjo5kDgE/8QgSf2Rn4kAOuPCdJCb2hYS231Uheh05qyc/nHokO6mIMNdf7fz3Sir mnfg== 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:references :mime-version:content-disposition:in-reply-to; bh=L3aQVmr3+G9IWrTH19z8a6mfU795FTG69R+rOcqJisg=; b=dukUKKZZCk7/CWZju7uBoRi7UNRe1IqAK4rRwlJzS61wdsAA3mmXFO6fb5WrJGLP8U ugCp3Gec98HMGyp3DtOqtJ+3xk8hSsFC+hmEYQ7YRcmwd6MOiJbW5eyX1eY9NUWywDCU vtXkOMGQeg8dDDuEuc+sf/qTZCPGmEVHZd6Uzpw9STwGcJvuTheo+FlVdJ7WIcnDtaVC ZU2VYNJo7DGIu0oJiNdPKYFmsq+gTC4nP/lnZGVDB5zzFWCMKDUhl97GFNWT3jZyfUVS tlZOOngufR83ZjBiz+eQPjb12udjbuBv9o2jqGY5ABYaOgw4ajyrS7rT5YW1+Pj7ZJMk cX8w== X-Gm-Message-State: AOAM531Lue+zRhS+P5M03I7WqC2VX3uWm5pFB0Sb8hAxEd6QdyFDGvJA 4Fy9bfvoyfXc1EJB0+S+VpnRpw== X-Google-Smtp-Source: ABdhPJzsSZZHaZsuPp/tYmInsqiMnK9ta08oNqLijbfVT7oV5kMNj480hYVB3apb/tmGasfJKloyrA== X-Received: by 2002:a05:600c:22d1:: with SMTP id 17mr15188808wmg.58.1600431779172; Fri, 18 Sep 2020 05:22:59 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id g14sm5319610wrv.25.2020.09.18.05.22.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2020 05:22:56 -0700 (PDT) Date: Fri, 18 Sep 2020 13:22:55 +0100 From: Jozef Lawrynowicz To: Florian Weimer Cc: Michael Matz , gnu-gabi@sourceware.org Subject: Re: [RFC] SHF_GNU_RETAIN ELF Section Flag Message-ID: <20200918122255.oqgufi3jkc72sgem@jozef-acer-manjaro> References: <20200915123155.xpow3oxpzycsq3ie@jozef-acer-manjaro> <87v9gfi5cf.fsf@oldenburg2.str.redhat.com> <87mu1ri4ie.fsf@oldenburg2.str.redhat.com> <20200915132955.gmklbme6h5x5izha@jozef-acer-manjaro> <30f44461-67b1-2428-7b0d-9a49520524b3@redhat.com> <20200915165255.fm53szwcabht77ig@jozef-acer-manjaro> <875z8dn9xj.fsf@oldenburg2.str.redhat.com> <87y2l770fl.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y2l770fl.fsf@oldenburg2.str.redhat.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: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2020 12:23:02 -0000 On Fri, Sep 18, 2020 at 02:07:42PM +0200, Florian Weimer wrote: > * Michael Matz: > > > Hello, > > > > On Wed, 16 Sep 2020, Florian Weimer via Gnu-gabi wrote: > > > >> * Jozef Lawrynowicz: > >> > >> > I suppose the most compelling use cases for SHF_GNU_RETAIN are when the > >> > dependency cannot be expressed with references to ELF sections. You > >> > can't use SHF_GROUP because there is nothing to group the section with. > >> > >> But if there is nothing to group the section with, why would the link > >> editor load the object? > >> > >> That's the part I don't understand. > > > > Hmm? By putting it on the command line: > > > > % ld --gc-sections needed.o > > > > should retain the RETAIN sections from needed.o, even if otherwise not > > seemingly referenced. > > But this use case already works today with an implicit linker script, I > think: > > $ cat needed-impl.S > .section .data.need-to-be-kept > symbol_to_be_retained: > .long 0 > $ cat needed.o > /* GNU ld script */ > INPUT (needed-impl.o) > SECTIONS { > .data : { > KEEP (*(.data.need-to-be-kept)) > } > } > $ gcc -c needed-impl.S > $ gcc -shared -Wl,--gc-sections needed.o > $ $ readelf -s a.out | grep symbol_to_be_retained > 35: 0000000000004020 0 NOTYPE LOCAL DEFAULT 20 symbol_to_be_retained > > (Some polishing by a linker expert is certainly needed, but I hope you > get the idea.) Yes, the use of the KEEP linker script directive is the current way to protect a section from garbage collection, but in my original proposal I outlined the benefits of using an attribute to save a section from garbage collection. For the attribute to work, you need a section flag to propagate the information to the linker. On Tue, Sep 15, 2020 at 01:06:32PM +0100, Jozef Lawrynowicz wrote: > ---------- > Motivation > ---------- > > ...snip... > > Currently, the KEEP linker script directive can be used to save a > section from garbage collection. The new SHF_GNU_RETAIN flag has the > same effect as KEEP, but since it is an ELF section flag, it means that > this property can be propagated through the toolchain, from the > compiler, through the assembler, to the linker. > > This enables a new "retain" attribute to be set on function and data > declarations in the source code, which communicates the need to set the > SHF_GNU_RETAIN flag on the containing section to downstream tools. In > some situations, this has benefits over applying the KEEP directive in > the linker script: > > - The requirement for protection from garbage collection might be > application-specific, so consolidating this requirement to be > contained entirely within the source code improves portability. > - The user doesn't have to work out which section a function or data > object declaration will be placed in, and then set the KEEP directive > on that section. They can just set the attribute in the source code > and leave the rest for the toolchain to handle. > - Generally avoiding linker script modifications can improve the user > experience, especially when the user is inexperienced with the linker > script format. The boilerplate linker script code required for > standard application operation can make modifications error-prone and > have unintended side-effects. So this new flag is not implementing a feature which is not currently possible to do in any other way, but it opens up new ways to modify the behavior of linker garbage collection, which can be used by developers and writers of libraries/SDKs. Thanks, Jozef