From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id 29C583858C27 for ; Sun, 28 Nov 2021 15:54:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 29C583858C27 Received: by mail-lf1-x12a.google.com with SMTP id k37so37994532lfv.3 for ; Sun, 28 Nov 2021 07:54:08 -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:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=W1X6Hl66COF0N4dAw3cgKEkcOkbKjZlivDCJbgWBK4g=; b=gERM6vLL6DtxBZ+qdW3dItgX3+gVTQOmWVUmi8zm/wecJwELR6lPzUv3w3b5UGqZAb zsMxUF+NALreeaImkgKJqVsEKvf0L7ZNBTlyIPWzi2KdeM2otBC8WOOJZE4pZpuYAVvs 0AzwhKIlTz/s5Kta9HbtoCKHPGUREdvlZzcPcHnUxE9VvQfZUqTKnK70riyFZNnsFfWz 2+p3ukp5H+nJzm68Voflg2l6swx2/GhRIxm8DcU23PGMQlr2L//ksRFlDBQazaALzrRh J5FgZ2d8m1E/Ugya1Eb9S9ey3/OHwOoZMBn+3XOTMurey7XXYVIQGmH5ob5Ejr59FHnA y9lw== X-Gm-Message-State: AOAM530M4rpY9hophCEsMREU7uyVA+g2Ty2mW34DxZQst7ovts6/9e94 BJQwR8MGMXa/R/Kxie3GkCo= X-Google-Smtp-Source: ABdhPJywx0Rvt7VNnT5rd58wlu4mFYni1UAgdc0EEy1GlAiRcTV/U6zhcVIeicr7guy5tNZ6MPkD2Q== X-Received: by 2002:a05:6512:39c7:: with SMTP id k7mr42560979lfu.571.1638114846881; Sun, 28 Nov 2021 07:54:06 -0800 (PST) Received: from [192.168.10.175] (37-247-29-68.customers.ownit.se. [37.247.29.68]) by smtp.gmail.com with ESMTPSA id t24sm1023975lfg.168.2021.11.28.07.54.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Nov 2021 07:54:06 -0800 (PST) Message-ID: Date: Sun, 28 Nov 2021 16:54:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Reserving specified size of RUNPATH entry in the dynamic section during linking Content-Language: en-US To: Florian Weimer Cc: Jacob Kroon via Gcc-help References: <09012276-6b9c-18a1-2e28-e4b7a42e6e22@gmail.com> <87o864h5c4.fsf@oldenburg.str.redhat.com> <1e0cb18e-e0fd-9f20-1037-84604a090a22@gmail.com> <87k0gsgvhg.fsf@oldenburg.str.redhat.com> From: Jacob Kroon In-Reply-To: <87k0gsgvhg.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2021 15:54:10 -0000 On 11/28/21 16:17, Florian Weimer wrote: > * Jacob Kroon: > >>> The RUNPATH strings are in the string table, so it's necessary to >>> allocate space there, and be able to find it during patching. >>> >>> Solaris offers this mechanism: >>> >>> | DT_SUNW_STRPAD >>> | >>> | The total size, in bytes, of the unused reserved space at the end of >>> | the dynamic string table. If DT_SUNW_STRPAD is not present in an >>> | object, no reserved space is available. >>> >>> Would that help in your case as well? >>> >> >> The problem is that for two different build I pass two different >> -Wl,--rpath=, and they are of different length. So I'd like to >> reserve a maximum size, at link-time, which becomes the same in both >> builds, so that when I later remove the rpath's, the binaries become >> identical. > > In the file, there is no array of some number of characters that > contains the null-terminated RUNPATH string, an array to which just more > null bytes could be added at the end. DT_RUNPATH contains an offset > into the string table. The null-terminated string could be used for > something else. For example, if the RUNPATH is > "/usr/lib64/sys/library.so.3", and the link edit needs the string > "library.so.3" for something else, it can point into the RUNPATH string > to get that. So it's not valid in general to patch the string in-place, > let alone change its length. > > That's why I think something like the Solaris approach is needed: The > new RUNPATH value would come from the reservation, the offset in > DT_RUNPATH points to it, and the original string table is not modified > at all. > Aha, thank you for explaining. I suppose gnu ld doesn't try to optimize for usage of substrings in RUNPATH, thus making if fairly easy to change it post linking. But can I then specify during link time that RUNTIME should go in a "reserved" area, whose size I can also control ? I hope I understood you correctly. Jacob