[Ltrace-devel] [PATCH v2] xtensa: add xtensa support
Petr Machata
pmachata at redhat.com
Sat Jan 3 14:53:50 UTC 2015
Max Filippov <jcmvbkbc at gmail.com> writes:
> Hi Petr,
>
> On Fri, Jan 2, 2015 at 4:32 AM, Petr Machata <pmachata at redhat.com> wrote:
>>> +int
>>> +arch_elf_init(struct ltelf *lte, struct library *lib)
>>> +{
>>> + Elf_Scn *scn;
>>> + GElf_Shdr shdr;
>>> + GElf_Addr relplt_addr;
>>> + GElf_Xword relplt_size;
>>> + GElf_Phdr phdr;
>>> + size_t i;
>>> +
>>> + for (i = 0; gelf_getphdr(lte->elf, i, &phdr) != NULL; ++i) {
>>> + if (phdr.p_type == PT_LOAD) {
>>> + lib->arch.loadable_sz =
>>> + phdr.p_vaddr + phdr.p_memsz - lte->bias;
>>
>> Was this tested on a prelinked system? It's confusing that you subtract
>
> No, it wasn't tested on a prelinked system, since AFAIK xtensa is not
> supported by the prelink.
Actually that was a thinko on my part. You are more likely to see a
non-zero bias on a non-prelinked system than prelinked one.
>> bias to get from ELF address to memory address. Normally you would add
>> it.
>>
>> Also, correct me if I'm wrong, but loadable_sz actually points to the
>> end of the region, and hence is not a size. Would loadable_end be a
>> better name?
>
> The intention was to calculate the size of loadable part of a library, to be
> able to tell later, given library base address and a pointer, if it
> points inside
> the library or outside of it.
Bias doesn't influence size, only the, um, "coordinate": where it's
mapped.
But anyway: your formula is p_vaddr + p_memsz ± bias. The first is a
coordinate, the second is size, adding the two together gives you
another coordinate (of the end of the buffer pointed to by p_vaddr).
Bias is again size, so the result is an address, not a size. Hence why
I think it's a misnomer.
Thanks,
Petr
More information about the Ltrace-devel
mailing list