From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 0762F393C84E for ; Tue, 15 Sep 2020 12:50:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0762F393C84E Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-501-3fAvKelZNWGiV7Ju0ddsMQ-1; Tue, 15 Sep 2020 08:50:02 -0400 X-MC-Unique: 3fAvKelZNWGiV7Ju0ddsMQ-1 Received: by mail-qt1-f197.google.com with SMTP id b18so2655009qto.4 for ; Tue, 15 Sep 2020 05:50:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zt+WBx88//Z6BRMYcTMPh8rXYbwRQg5Kg5FRRtu9++E=; b=IQ8iETytcETBiQZ+YAZhP2CM3FEwajfh+tEvrih9+YRf5McAbkI8mH/InzinXOajkC slH1jyU/pewMHKsmEBD2cAbdoyQiJj49rNOVfP+rQAUgOJwa09HP2WxZDi8zQWcdxuch MnsN1vHSn80yG3ewDFEExNkRwpaDlDMDng4Xcv5SD3Pog147qJv+Oz4RVc9HGK1FBy0B SEbX967jxVdeaOUdHBN+ftiZADSac+oy1coA+IgBmO/vs3+MBVBcMKSNjidyjrf03R6+ 6hwG1hdrOc5EuUmK29TO6BaeRA6WiT4MXgfkZRUyykWplVMXnhQ2CEDjs10Cf6tpDxUV WbOw== X-Gm-Message-State: AOAM532Pr2T0FxlvjarRme1ySOzrG9Fp1Q021SLj914LHvfRq85T5TOR LaP/DIWxFR5waAU3WhY9p0pwyFZuEYe9V/rvunIpxYRt2tmu5/W2MF5Dfn3lkQ89kquHb+tC//g fP/bzdzhG/eOfL2nhQA== X-Received: by 2002:aed:3bf1:: with SMTP id s46mr5466293qte.389.1600174202030; Tue, 15 Sep 2020 05:50:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzpvvNDRsL+OSHwCudu402Llk99UbZBE5bh3rlp3JH+peX9Yo9J2DGSHfMz37d0diGexIk78A== X-Received: by 2002:aed:3bf1:: with SMTP id s46mr5466274qte.389.1600174201799; Tue, 15 Sep 2020 05:50:01 -0700 (PDT) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id v16sm15872333qkg.37.2020.09.15.05.50.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2020 05:50:01 -0700 (PDT) Subject: Re: [RFC] SHF_GNU_RETAIN ELF Section Flag To: Florian Weimer , Jozef Lawrynowicz Cc: gnu-gabi@sourceware.org References: <20200915120632.bs36vkrbvmsoyvnu@jozef-acer-manjaro> <877dsvjl71.fsf@oldenburg2.str.redhat.com> <20200915123155.xpow3oxpzycsq3ie@jozef-acer-manjaro> <87v9gfi5cf.fsf@oldenburg2.str.redhat.com> From: Carlos O'Donell Organization: Red Hat Message-ID: Date: Tue, 15 Sep 2020 08:50:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <87v9gfi5cf.fsf@oldenburg2.str.redhat.com> X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, 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: Tue, 15 Sep 2020 12:50:07 -0000 On 9/15/20 8:37 AM, Florian Weimer via Gnu-gabi wrote: > * Jozef Lawrynowicz: > >> On Tue, Sep 15, 2020 at 02:09:22PM +0200, Florian Weimer wrote: >>> * Jozef Lawrynowicz: >>> >>>> I'd like to propose a new ELF section flag, SHF_GNU_RETAIN, for addition >>>> to the GNU gABI. >>>> >>>> This flag instructs the linker to "retain" the section in the output >>>> file, even if garbage collection would remove it because it appears >>>> unused. >>> >>> How does this flag interaction with libraries (.a files)? >> >> If a section in a library has SHF_GNU_RETAIN set, and that library gets >> searched by the linker for some undefined symbol, then the >> SHF_GNU_RETAIN section will also be pulled into the program, and >> retained in the linked output file. > > Sorry, that's not quite what I meant. What happens if the .o file with > SHF_GNU_RETAIN in an .a library is not otherwise referenced and thus > never loaded by the link editor? How would the link editor realize that > it is even there? Why would it be loaded? Why does the link editor need to detect the presence of such a file? There is certainly a semantic layering here that needs to be teased apart and explained in more detail. The archive operates on whole object files. Therefore the rules say that the whole object file is included when a dependency would require it to be included. While SHF_GNU_RETAIN operates on sections. So when the linker is doing garbage collection of the included section it would keep the section. Thus the definition of SHF_GNU_RETAIN might be: SHF_GNU_RETAIN When an object file containing such a marked section is included in the link, the section should not be garbage collected by the linker, even if it appears unused. This would do away with the archive ambiguity. Unless we want to argue what we mean by "included in the link?" -- Cheers, Carlos.