From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by sourceware.org (Postfix) with ESMTPS id 9AB51386F001 for ; Wed, 16 Sep 2020 14:13:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9AB51386F001 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-x343.google.com with SMTP id s13so2939683wmh.4 for ; Wed, 16 Sep 2020 07:13:48 -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:mime-version:content-disposition :in-reply-to; bh=HkXHiTWYt6OTECf1cvicC//EIn9vEtaMjAkBUB9T+LU=; b=MhjRuCfYIRFQIwqUcZreOYIRaJg62tHqohm0GgYoHuZ2tinvDrJYZ1snKirUfzXaYR aR5R/y26u+z/e8aPnPCVuhaBzSC5ScaLhU9aXwfQXdjXSMVCs/OzFwp1BALbGmfU+CfV LNhl2Qm8zLDb9mcsXwiEYihgUGwwfsTg3jX/rvfUHucMhskD6g8/YMnN1iE8RKfB6tnk kK2oMj4JIJgZ4UYHvAcCx/H2u0u6MluN+3fhJISeqO47OSbxKnbWjD4a/ea36JSqbqTh 5DNNliP6sJQKV9/5IDUPrRCyt6JIR/rKeVx4r1XPuXd05cp7WoNq1UlcXlqoqCGlIV27 OnHw== 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:mime-version :content-disposition:in-reply-to; bh=HkXHiTWYt6OTECf1cvicC//EIn9vEtaMjAkBUB9T+LU=; b=eCzNPBEYEPfNIcg61Xvddf/YCDxQiCd3BLWTJTw+bOsTLdusPHSt9AtRHhedx+leEU CttwPStR4Me/J8WmHPLbF1t4igL5nk/pq2CHgYv50yl9/KdYefOMNh5aI337X8TFZbjL 1iSBncwg3MdhODIwaMAc91K+yoxP/NTtUqer4qLffSczPy8xXGGWFCuKdsEcG+uMqthL gEAwWri5diLhlzZWwveXAEz0tGlxLRFg5Sw8sPKz/dVMgphIt+Z6/xNVcXo8iCz/Go7N tfV0phVv1dvDh2j0XMEWn3pVqRk0lXPK7uTkJOPAc2bW3ZhbQYqGU6gy3mU55217hN24 epCw== X-Gm-Message-State: AOAM530n4aqIMU0yyXb26kSq5yG6AFKmtAFlYyvqgBEEPE19gTNh4z6Z +WhY03AtvEgduLxPTYjEphh6vWxxQ0vQVw== X-Google-Smtp-Source: ABdhPJzLKBdlshbac87lxAL5ud400cBm4NGov0muWfHmkqLmVEH/RepPga0OaBG8QX6EWEnxW4slzQ== X-Received: by 2002:a1c:59c3:: with SMTP id n186mr5010337wmb.32.1600265627716; Wed, 16 Sep 2020 07:13:47 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id 91sm36484295wrq.9.2020.09.16.07.13.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2020 07:13:47 -0700 (PDT) Date: Wed, 16 Sep 2020 15:13:45 +0100 From: Jozef Lawrynowicz To: Carlos O'Donell , Florian Weimer Cc: gnu-gabi@sourceware.org Subject: Re: [RFC] SHF_GNU_RETAIN ELF Section Flag Message-ID: <20200916141345.wxae5ytkyybbpcec@jozef-acer-manjaro> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95e4fd3d-1486-b700-29b0-8b126b24d0ca@redhat.com> <875z8dn9xj.fsf@oldenburg2.str.redhat.com> X-Spam-Status: No, score=-5.2 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: Wed, 16 Sep 2020 14:13:50 -0000 On Wed, Sep 16, 2020 at 08:58:41AM -0400, Carlos O'Donell wrote: > On 9/15/20 12:52 PM, Jozef Lawrynowicz wrote: > > 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. > > GRP_KEEP - Group of sections to always keep. Never discarded if included > in the link. > > The benefit is you can give them a logical group name e.g. "cpu_features" > and have more than one of them for accounting/documentation purposes. > > You can implement a "KEEP" source markup based on gas' .section directive? This is an interesting idea, but my initial thoughts are that it adds some complexity that I don't think is required. There is already a lot of information that can be gleaned from the section header, and the symbols within that section. Presumably the developer would have named the ISR/memory mapped register symbol sensibly. It doesn't seem very standard to make use of ELF constructs for documenting why something has been done a certain way. You would just use the construct to make something happen and have the "why" documented elsewhere. On Wed, Sep 16, 2020 at 03:11:20PM +0200, Florian Weimer 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. Well this is intended for use by application code rather than libraries. So all the objects that are part of the specific application and explicitly passed to the link editor are going to be loaded. (Please forgive any technical misuse of "application" above, but I hope it is clear what I mean ;)) If a developer wants to use it in a library they'll have to take precautions that it behaves as expected, by considering the object file that the SHF_GNU_RETAIN section would reside in. Thanks, Jozef