Hi,
It has been brought to my attention that on systems where the text
of shared libs is not loaded with a zero virtual address, perf report
fails to symbolize
correctly samples. This is true of older versions of perf and also the latest
in tip.git.
I looked at symbol-elf.c and I did not see a place where the vaddr was taken
into account from the program headers in the case of ET_DYN. I see it for
ET_EXE, though.
$ readelf -e lib.so
Type: DYN (Shared object file)
....
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000d000 0x0000d000 0x73657c 0x73657c R E 0x1000
If you get samples in the shared lib, they will be off, possibly
attributed to the wrong
functions.
Could this be fixed quickly?
Thanks.
Em Tue, Jun 16, 2015 at 12:03:01AM -0700, Stephane Eranian escreveu:
> Hi,
>
> It has been brought to my attention that on systems where the text
> of shared libs is not loaded with a zero virtual address, perf report
> fails to symbolize
> correctly samples. This is true of older versions of perf and also the latest
> in tip.git.
>
> I looked at symbol-elf.c and I did not see a place where the vaddr was taken
> into account from the program headers in the case of ET_DYN. I see it for
> ET_EXE, though.
>
> $ readelf -e lib.so
> Type: DYN (Shared object file)
> ....
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x000000 0x0000d000 0x0000d000 0x73657c 0x73657c R E 0x1000
>
> If you get samples in the shared lib, they will be off, possibly
> attributed to the wrong
> functions.
>
> Could this be fixed quickly?
You tell me, do you have a patch to propose? :-)
- Arnaldo
On Tue, Jun 16, 2015 at 7:34 AM, Arnaldo Carvalho de Melo
<[email protected]> wrote:
> Em Tue, Jun 16, 2015 at 12:03:01AM -0700, Stephane Eranian escreveu:
>> Hi,
>>
>> It has been brought to my attention that on systems where the text
>> of shared libs is not loaded with a zero virtual address, perf report
>> fails to symbolize
>> correctly samples. This is true of older versions of perf and also the latest
>> in tip.git.
>>
>> I looked at symbol-elf.c and I did not see a place where the vaddr was taken
>> into account from the program headers in the case of ET_DYN. I see it for
>> ET_EXE, though.
>>
>> $ readelf -e lib.so
>> Type: DYN (Shared object file)
>> ....
>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
>> LOAD 0x000000 0x0000d000 0x0000d000 0x73657c 0x73657c R E 0x1000
>>
>> If you get samples in the shared lib, they will be off, possibly
>> attributed to the wrong
>> functions.
>>
>> Could this be fixed quickly?
>
> You tell me, do you have a patch to propose? :-)
>
Well, need to make sure I understand the code flow in dso__load_sym()
and callers.
You have elf_read_maps() which seems to be reading the phdr but, it would need
to be called systematically for ET_DYN. I will experiment with this.
Worst case, we
need to add another function to read the phdr and use the p_vaddr.
Em Wed, Jun 17, 2015 at 11:54:12AM -0700, Stephane Eranian escreveu:
> On Tue, Jun 16, 2015 at 7:34 AM, Arnaldo Carvalho de Melo <[email protected]> wrote:
> > Em Tue, Jun 16, 2015 at 12:03:01AM -0700, Stephane Eranian escreveu:
> >> If you get samples in the shared lib, they will be off, possibly
> >> attributed to the wrong
> >> functions.
> >>
> >> Could this be fixed quickly?
> >
> > You tell me, do you have a patch to propose? :-)
> Well, need to make sure I understand the code flow in dso__load_sym()
> and callers.
> You have elf_read_maps() which seems to be reading the phdr but, it
> would need to be called systematically for ET_DYN. I will experiment
> with this.
> Worst case, we need to add another function to read the phdr and use
> the p_vaddr.
Ok, that symbols* code grew unwieldly complex, need to give it some love and
refactoring care at some point...
Thanks!
- Arnaldo