From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: "H.J. Lu" <hjl.tools@gmail.com>, Lukasz Majewski <lukma@denx.de>
Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>,
Florian Weimer <fweimer@redhat.com>,
libc-alpha <libc-alpha@sourceware.org>,
Andreas Schwab <schwab@linux-m68k.org>,
Joseph Myers <joseph@codesourcery.com>
Subject: Re: [PATCH] dl: Use "adr" assembler command to get proper load address
Date: Mon, 11 Oct 2021 10:34:24 -0300 [thread overview]
Message-ID: <85f5206e-7f3e-01a1-d149-25a1506bdd7a@linaro.org> (raw)
In-Reply-To: <CAMe9rOoCc+40-_r5rPuC00kLDexd=xzLXib3GfBM7KNuU6R-dA@mail.gmail.com>
On 11/10/2021 09:01, H.J. Lu wrote:
> On Mon, Oct 11, 2021 at 4:47 AM Lukasz Majewski <lukma@denx.de> 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.
next prev parent reply other threads:[~2021-10-11 13:34 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-07 13:16 Lukasz Majewski
2021-09-07 16:49 ` Fangrui Song
2021-09-07 17:32 ` Lukasz Majewski
2021-09-07 17:44 ` Fangrui Song
2021-09-08 15:05 ` Lukasz Majewski
2021-09-08 17:41 ` Fāng-ruì Sòng
2021-09-08 19:19 ` Adhemerval Zanella
2021-09-08 20:34 ` Lukasz Majewski
2021-09-09 7:18 ` Lukasz Majewski
2021-09-09 9:49 ` Lukasz Majewski
2021-09-10 10:10 ` Lukasz Majewski
2021-09-17 8:29 ` Lukasz Majewski
2021-09-17 13:27 ` Joseph Myers
2021-09-17 16:17 ` Andreas Schwab
2021-09-26 19:58 ` Lukasz Majewski
2021-09-27 16:00 ` Joseph Myers
2021-10-05 7:45 ` Lukasz Majewski
2021-10-06 7:57 ` Fangrui Song
2021-10-06 9:03 ` Lukasz Majewski
2021-10-06 11:43 ` Lukasz Majewski
2021-10-06 12:55 ` Szabolcs Nagy
2021-10-07 9:19 ` Lukasz Majewski
2021-10-07 10:00 ` Lukasz Majewski
2021-10-07 14:15 ` Szabolcs Nagy
2021-10-07 14:58 ` Lukasz Majewski
2021-10-07 14:16 ` Adhemerval Zanella
2021-10-07 14:29 ` H.J. Lu
2021-10-07 15:57 ` Szabolcs Nagy
2021-10-07 16:22 ` H.J. Lu
2021-10-07 16:53 ` Adhemerval Zanella
2021-10-07 17:05 ` H.J. Lu
2021-10-07 17:24 ` Fāng-ruì Sòng
2021-10-08 9:15 ` Szabolcs Nagy
2021-10-11 8:56 ` Lukasz Majewski
2021-10-11 10:18 ` Szabolcs Nagy
2021-10-11 11:47 ` Lukasz Majewski
2021-10-11 12:01 ` H.J. Lu
2021-10-11 13:10 ` Lukasz Majewski
2021-10-11 13:22 ` H.J. Lu
2021-10-11 14:31 ` Lukasz Majewski
2021-10-11 13:34 ` Adhemerval Zanella [this message]
2021-10-11 12:48 ` Szabolcs Nagy
2021-10-15 7:54 ` [PATCH v2] dl: Use "adr" assembler command to get proper load address on ARM Lukasz Majewski
2021-10-15 12:09 ` Szabolcs Nagy
2021-10-15 12:21 ` H.J. Lu
2021-10-15 12:59 ` Lukasz Majewski
2021-10-15 23:53 ` Fāng-ruì Sòng
2021-10-18 11:08 ` Szabolcs Nagy
2021-10-18 11:35 ` Florian Weimer
2021-10-19 12:03 ` Lukasz Majewski
2021-10-25 10:18 ` Lukasz Majewski
2021-10-25 10:25 ` Florian Weimer
2021-10-25 10:53 ` Lukasz Majewski
2021-10-25 13:34 ` Szabolcs Nagy
2021-10-25 14:04 ` Lukasz Majewski
2021-10-25 15:09 ` Szabolcs Nagy
2021-10-25 17:26 ` Joseph Myers
2021-10-26 13:52 ` Lukasz Majewski
2021-10-26 20:55 ` Joseph Myers
2021-10-27 9:38 ` Szabolcs Nagy
2021-10-25 18:25 ` Lukasz Majewski
2021-10-15 13:59 ` Lukasz Majewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85f5206e-7f3e-01a1-d149-25a1506bdd7a@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=lukma@denx.de \
--cc=schwab@linux-m68k.org \
--cc=szabolcs.nagy@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).