From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 6E5033858D28 for ; Mon, 11 Oct 2021 13:23:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6E5033858D28 Received: by mail-pl1-x632.google.com with SMTP id y1so11283809plk.10 for ; Mon, 11 Oct 2021 06:23:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WAmR83aUctHROxd4oNJAa1NIwzTDxs5GI4GlhFx/sgE=; b=xEVBbCY6DnGNeoEZ8u1p/SH9+2qtTZN5cODab4zoDNmBBn2UrRH9YlfU6sINUB2QIo g6WLj44lFQ/RB33wYn+2iCraoWvnoHy4j2OX3002YbzoM92ZjurS52FbqRl2ITP5KM3h KA2gZZwLGb4kIFFwg0vn6H57Zzm4mbp5wgJETxB1ky3wXZIMW4qxcFKWqfKQlFbLTEDk Tm+TezXs+u5tMgM8YQlVbynWIUfnvwbjP6MamCgPrZotLS5AcH5SiuzYQowLZTYzxTmo 6fd1bOBsVC6U/zKPzHuxbh4MdFMmGEX026/KdMf86ihA0KdRqoOMfBM9I/ayGLEhnZhw R3IQ== X-Gm-Message-State: AOAM531rrVvRTTUWizVxNzxkU0AfsHLo3TEdEA14VB5ycJG9ArLR3wQh OuO6HkXIwcwR8N7I/bxhOEC80tlWkOG6mRnnOIg= X-Google-Smtp-Source: ABdhPJxAQwr6t4ISQT8QVH+TVyU0wdyHGOgNbucRLK5JHtIE6jLpejZ6iV6M9tz6R7xVHSHXAZCwN9w7V8m5V7B3by0= X-Received: by 2002:a17:90a:a60c:: with SMTP id c12mr31294434pjq.28.1633958609447; Mon, 11 Oct 2021 06:23:29 -0700 (PDT) MIME-Version: 1.0 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> <20211011151007.2903e38b@ktm> In-Reply-To: <20211011151007.2903e38b@ktm> From: "H.J. Lu" Date: Mon, 11 Oct 2021 06:22:53 -0700 Message-ID: Subject: Re: [PATCH] dl: Use "adr" assembler command to get proper load address To: Lukasz Majewski Cc: Szabolcs Nagy , Adhemerval Zanella , Florian Weimer , libc-alpha , Andreas Schwab , Joseph Myers Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3023.3 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.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:23:31 -0000 On Mon, Oct 11, 2021 at 6:10 AM Lukasz Majewski wrote: > > On Mon, 11 Oct 2021 05:01:23 -0700 > "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. > > prelink is used also to speed things up. In some use cases - boot time > optimization (like kiosk, or automotive) the bootup time is crucial. I am NOT asking you to remove prelink. I am only asking not to run prelink on ld.so. Do you have bootup time data on ld.so with and without prelink? > IMHO, the change with __ehdr_start introduced regression and hence > shall be fixed so the previous behaviour is preserved. > -- H.J.