From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) by sourceware.org (Postfix) with ESMTPS id B61A93858D28 for ; Mon, 11 Oct 2021 13:34:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B61A93858D28 Received: by mail-ua1-x931.google.com with SMTP id h4so12843595uaw.1 for ; Mon, 11 Oct 2021 06:34:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hzyUAdSyKcEjtJdguH2v+pKSkn1cG65jRTzfzEzyk2Q=; b=g4hOBSKJgapllntank8I1/MwstbL2pWoDyNSFjuXCuXXT49dQNuWRyPLd4RF5LcwEW ExCKj9Nr1yUxWpCI7ZFN27OngNcsupLbpe2xWEoLMXLBmkNc6p+FcGNK8gaDGnejfuT0 IWZO8NORaI6PcAuEFotKv0TZHd5kclJ6WGUWyqTigPCgKoH/EkOih0p4nQqWksfLreki vdxFP1z6YZOGtw2/oBfr7dLQY4vjxW1mc4/bHXRff8Ra8Z/LggtWX56Q/mvQfTtwB1dy U86WlnmELvlkSu/5FL7npdQSc5a5AIWDUCtNGUYW3FCFhJpR8qa7PEnLW1u6gWw2pN3Q XBgw== X-Gm-Message-State: AOAM530N9ihAtWxylf5OdmxpqSLiFKBSVIAy53muUKeRgESQTrULn0Ny ejqVEkmxyFrzUn3OthC1wcIkVw== X-Google-Smtp-Source: ABdhPJzvngorw1R1CsJwnNsbKh2d3e5qncTlpqgbAAfimUumndEhlU5MpReWl9fqdGwYOF7YR2qoQw== X-Received: by 2002:a67:2d16:: with SMTP id t22mr22606057vst.1.1633959266949; Mon, 11 Oct 2021 06:34:26 -0700 (PDT) Received: from ?IPv6:2804:431:c7cb:807a:d3d9:54fd:9a6e:6970? ([2804:431:c7cb:807a:d3d9:54fd:9a6e:6970]) by smtp.gmail.com with ESMTPSA id k1sm3190233uaq.0.2021.10.11.06.34.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Oct 2021 06:34:26 -0700 (PDT) Subject: Re: [PATCH] dl: Use "adr" assembler command to get proper load address To: "H.J. Lu" , Lukasz Majewski Cc: Szabolcs Nagy , Florian Weimer , libc-alpha , Andreas Schwab , Joseph Myers References: <20211005094554.2f28d6bd@ktm> <20211006075721.qnv6qabroytcsido@google.com> <20211006110321.5f1a9610@ktm> <20211006134344.63395242@ktm> <20211006125517.GE2700@arm.com> <20211007111926.30db4c4f@ktm> <20211007120038.1445bbd3@ktm> <44bac775-3127-7bc7-c4ea-fa282ed277d3@linaro.org> <20211011105617.5bcd493d@ktm> <20211011101839.GJ2700@arm.com> <20211011134736.57e763ba@ktm> From: Adhemerval Zanella Message-ID: <85f5206e-7f3e-01a1-d149-25a1506bdd7a@linaro.org> Date: Mon, 11 Oct 2021 10:34:24 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 13:34:31 -0000 On 11/10/2021 09:01, H.J. Lu wrote: > On Mon, Oct 11, 2021 at 4:47 AM Lukasz Majewski wrote: >> >> Hi Szabolcs, >> >> Thank you very much for your input. >> >>> The 10/11/2021 10:56, Lukasz Majewski wrote: >>>> Do we have _any_ plan how to fix it? BSPs for many boards are built >>>> with Yocto/OE nowadays... >>>> >>>> The approach with using 'adr' (pseudo) assembler instruction to >>>> calculate the on-runtime addresses was working previously. >>>> >>>> Shall we revert changes which were introduced recently (to use >>>> __ehdr_start)? >>> >>> the reason for the change was to avoid relying on GOT[0]. >> >> And why it is requested to not relying on GOT[0]? >> >>> >>> i guess we can revert elf_machine_load_address on arm, but >>> keep the new elf_machine_dynamic that does not rely on GOT[0]. >> >> This was the approach proposed by this patch. >> >>> >>> it is also useful to have the same c code across targets >>> for the load address. if we want to do that and support >>> vaddr!=0 for ehdr then i think it can be (untested): >>> >>> __attribute__ ((const)) ElfW(Addr) >>> load_addr (void) >>> { >>> extern const ElfW(Ehdr) __ehdr_start __attribute__ ((visibility >>> ("hidden"))); ElfW(Addr) addr = (ElfW(Addr)) &__ehdr_start; >>> ElfW(Word) phnum = __ehdr_start.e_phnum; >>> const ElfW(Phdr) *phdr = (const void *) (addr + >>> __ehdr_start.e_phoff); const ElfW(Phdr) *ph; >>> assert (__ehdr_start.e_phentsize == sizeof *phdr); >>> for (ph = phdr; ph < &phdr[phnum]; ++ph) >>> if (ph->p_type == PT_LOAD && ph->p_offset == 0) >>> { >>> addr -= ph->p_vaddr; >> >> The above line is a bit strange for me. Isn't the p_offset set by >> prelink as well? >> >> And most of all - why do we need to perform relocation in such very >> early stage of the ld-linux-armhf.so.3 ? >> >>> break; >>> } >>> return addr; >>> } >>> >>> i don't have a strong preference either way: >>> 1) fix yocto >> >> Yocto by default uses prelinkg from the very long time. I think that it >> would be very difficult to change that. > > Just don't run prelink on ld.so since the load address is controlled > by kernel. I think it would be better to fail early on ld.so with a meaningful warning to avoid the possible issues. Another solution would be to ignore the entrypoint value set by prelink for the loader and always use 0.