[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