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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 25C9F3858D39 for ; Mon, 24 Jan 2022 16:24:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 25C9F3858D39 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-623-lYrMPK8rPDuacVSISq3uLA-1; Mon, 24 Jan 2022 11:24:37 -0500 X-MC-Unique: lYrMPK8rPDuacVSISq3uLA-1 Received: by mail-wm1-f69.google.com with SMTP id l16-20020a1c7910000000b0034e4206ecb7so145389wme.7 for ; Mon, 24 Jan 2022 08:24:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:cc:from:subject:in-reply-to :content-transfer-encoding; bh=3gL/uiRGFtBwUbBbDi8Ehm5bjUswodpNThwSPjATdd8=; b=ZIfj+RxKtgqVzqUFpYJcSCPJNThYcosp1XOefcIFbwWGCJfWX5d9aYLyYxVU0N1OSe PFQJTpGtjAQDt+THNxiGfZ0zuGkPNU7klBS/yLZuzdLWNVxkxe3AlCQcLU4Gp9W3BSUG NxGVUttQ+hgJQ2Q05amwBm4U24KjcBUXYPS1MGDtNL9dpkfE1G3TKww9pDr+HtxXEnJk /EF59bHmgwLowXctxbvrgpPikVmrVGI+Ru7NzlX6D0ksD8ABkgSKug9+6ncdWXCuVbaR wDnB9E4o25R7e9E59tEANxSkPs/Suy8wYTLFTTV8QyLYCxs5g1GQLp61veEB53QYlEGK /WhA== X-Gm-Message-State: AOAM532V/LTuI+g14fa7MOmIUSuuyWO39iK1QDFKECnjr3UnbOyDrtQ2 j1jupd5aJ+ulcCRizNiqabSE2LtfTl2sFcA1ixE8VZxqpWgD9OHJYlAOlp5Uk3EQbXrZomcanzZ JDlVZZ5cO4+zld3zhxQ== X-Received: by 2002:adf:9f14:: with SMTP id l20mr14858172wrf.65.1643041475905; Mon, 24 Jan 2022 08:24:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJw4dWZ5kSKzCV9S9c4/efG4MFFbg3tygEAXc1ElYqIW9+8mDw3jb+GUQGDeAovOz61PT2c0hA== X-Received: by 2002:adf:9f14:: with SMTP id l20mr14858146wrf.65.1643041475695; Mon, 24 Jan 2022 08:24:35 -0800 (PST) Received: from [192.168.1.6] (adsl-164-239.freeuk.com. [80.168.164.239]) by smtp.gmail.com with ESMTPSA id l24sm13141105wme.17.2022.01.24.08.24.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Jan 2022 08:24:35 -0800 (PST) Message-ID: <5448901b-167d-4423-c99e-557d8178e56d@redhat.com> Date: Mon, 24 Jan 2022 16:24:33 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 To: "H.J. Lu" References: <20220111021241.1937265-1-hjl.tools@gmail.com> Cc: Binutils From: Nick Clifton Subject: Re: Fwd: [PATCH v2] ld: Rewrite lang_size_relro_segment_1 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 24 Jan 2022 16:24:40 -0000 Hi H.J. > Here is the v2 patch to track the maximum section alignment from > the RELRO segment.  If the maximum page size >= the maximum > section alignment, we can align the RELRO segment to the maximum > page size. I am having some trouble getting my head around this patch, so please bare with me if I ask some silly questions: /* Find the first section in the relro segment. */ for (sec = link_info.output_bfd->section_last; sec; sec = sec->prev) if ((sec->flags & SEC_ALLOC) != 0) { if (last_sec_status != relro_sec_before && sec->alignment_power > max_alignment_power) max_alignment_power = sec->alignment_power; if (sec->vma >= seg->base && sec->vma < seg->relro_end - seg->relro_offset) { relro_sec = sec; prev_sec = sec->prev; last_sec_status = relro_sec_in; } else last_sec_status = relro_sec_before; } Questions: Should a zero-sized section (with SHF_ALLOC) be treated as a viable candidate ? Once last_sec_status has been set to relro_sec_before, is there any point in continuing the scan ? If the section list contains a section which starts beyond the end of the segment (ie sec->vma >= seg->relro_end - seg->relro_offset) then a) is this an error ? and b) should its alignment power be considered against max_alignment_power ? if (relro_sec) { /* Where do we want to put this section so that it ends as desired? */ By "desired" I assume you mean "with the desired alignment, but without any unnecessary padding". Is that correct ? /* Find the first non-empty preceding section. */ for (; prev_sec; prev_sec = prev_sec->prev) if (prev_sec->size != 0 && (prev_sec->flags & SEC_ALLOC) != 0) break; Given that prev_sec is only needed later on, inside an if-statement, you could move this loop - potentially saving a bit of time in some cases. Overall I think that the code could use some more comments, explaining what is going on with some examples of how each part of the algorithm operates. Cheers Nick