From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by sourceware.org (Postfix) with ESMTPS id B4395385E018; Tue, 7 Apr 2020 16:37:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B4395385E018 Received: by mail-io1-xd33.google.com with SMTP id y17so4000929iow.9; Tue, 07 Apr 2020 09:37:19 -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:cc; bh=vcPY1Z8PLz7JUeV0iBphENzipuZrHPNXK33QAoPk7aI=; b=ijlXHCeBVUnfvWSHpDeja62jcIR15NvymT5sGvXMzbJTwH8mzjy9Iqf2xwA8+aA5uM OUIOyhVliJnYlqWjrDzgGfZ+2OEYbJxZ0MMQMGWoK/BFsCB9a96mbgjFHvJl0wfe8Evp RKESuR5t9RAhItmQH2yiSnS5GDPhmf79yD7yxLlpapOOMShWtOVv0NQmEFR2OgHBGeoE y3qR68CPzyAeKCcCtIhSLB71UA4Q/AMfTFhtkEhu/lkcigY7w7kvAJGNtv2BeAvmoHYC 9gOiGqykurXeBiJfO2LMTbL4V9QOkCkL/M/1MkQiKKHuQ5vJY2eiKVy2mgFFKHTihmwD CYpg== X-Gm-Message-State: AGi0PubTd0mSHRLKJ7Xi//z4Ud9cpbTQgWSKAIBZVVprvmGChzw0EuXL /30w6zM4JOGgaWyXbhea5Ho4GX8/JEayRYFCpXM= X-Google-Smtp-Source: APiQypLkXPsQ1UzBjJ115nQh46nd6Mdw/ieETBZPysEmlQdqsgTjt/uFFG4g5PdduVZmkR8TWv4Nq/4aAK9135PUGAA= X-Received: by 2002:a05:6602:1234:: with SMTP id z20mr2982945iot.20.1586277439160; Tue, 07 Apr 2020 09:37:19 -0700 (PDT) MIME-Version: 1.0 References: <20200328042257.3scmekcyrii527ta@gmail.com> <87lfnkdcbn.fsf@mid.deneb.enyo.de> <20200407025119.iapvp3gyck7ziilr@gmail.com> <20200407031817.jyqxtxdgnpqpsp72@gmail.com> <20200407061016.dkrfo4c5u37ck5qf@gmail.com> In-Reply-To: <20200407061016.dkrfo4c5u37ck5qf@gmail.com> From: Cary Coutant Date: Tue, 7 Apr 2020 09:37:07 -0700 Message-ID: Subject: Re: [ld] Allow custom sections to be under PT_GNU_RELRO To: Fangrui Song Cc: Florian Weimer , Binutils , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 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: 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, 07 Apr 2020 16:37:21 -0000 > For that case, inventing new stuff DT_GNU_RELRO/DT_GNU_RELROSZ is not > really meaningful. Rich Felker reminded me that this is about how > segments are mapped/protected. PT_* (the current design) is more > appropriate. I disagree with this, but not strongly. I believe that the program header table entries are for the kernel loader, and the more things we add there for the dynamic loader means more spam that the kernel loader has to sift through. Of course, PT_DYNAMIC is needed, but once we have that, the dynamic loader can find everything else it needs in the dynamic table. I think PT_xxx_UNWIND probably should have been a pair of dynamic table entries, too (that might fit in with Rich's logic). If I were designing ELF from scratch, I'd be tempted to combine the program header table and the dynamic table into one, perhaps partitioning it so that kernel-significant entries all come first. -cary