Re: [PATCH] perf tools: don't adjust symbols in vDSO

[Will Deacon]

(CC'ing Andy, since the removal of VDSO_PRELINK is user-visible here)

Hi Adrian,

Thanks for your helpful responses.

On Fri, Jun 26, 2015 at 02:55:29PM +0100, Adrian Hunter wrote:
> On 26/06/15 15:23, Will Deacon wrote:
> > On Thu, Jun 25, 2015 at 02:32:13PM +0100, Adrian Hunter wrote:
> >> On 24/06/15 19:17, Will Deacon wrote:
> >>> Commit 922d0e4d9f04 ("perf tools: Adjust symbols in VDSO") changed the
> >>> ELF symbol parsing so that the vDSO is treated the same as ET_EXEC and
> >>> ET_REL binaries despite being an ET_DYN.
> >>>
> >>> This causes objdump, which expects relative addresses, not to produce
> >>> any output in conjunction with perf annotate, which cheerfully passes
> >>> absolute addresses when trying to disassemble vDSO functions.
> >>>
> >>> This patch avoids marking the vDSO as requiring adjustment of symbol
> >>> addresses, allowing the relative program counter to be used instead.
> >>>
> >>> Cc: Vladimir Nikulichev <nvs@xxxxxxxxxxx>
> >>> Cc: Adrian Hunter <adrian.hunter@xxxxxxxxx>
> >>> Cc: Namhyung Kim <namhyung@xxxxxxxxxx>
> >>> Reported-by: Kristina Martsenko <kristina.martsenko@xxxxxxx>
> >>> Signed-off-by: Will Deacon <will.deacon@xxxxxxx>
> >>> ---
> >>>
> >>> Not sure why I've just started seeing this, but it appears to affect
> >>> both x86 and arm64. Also, if I revert the patch above then the issue
> >>> it supposedly fixed doesn't resurface. Maybe it was just masking another
> >>> bug that has since been addressed?
> >>
> >> No the problem still appears on older kernels.
> > 
> > Can you be more specific, please? I tried with a 3.16 kernel (that I happen
> 
> 3.13 Ubuntu kernel

So I just tried that on a core2 box and it's broken even without my patch:

# ./perf record -e cycles:u  ./vdso-test
[...]
# ./perf report
[...]
# Overhead  Command    Shared Object      Symbol
# ........  .........  .................  ........................
#
    99.70%  vdso-test  [vdso]             [.] __vdso_clock_gettime
[...]
# ./perf annotate -v
[...]
annotating [0x2178d10]                         [vdso] : [0x258bbd0]           __vdso_clock_gettime
Executing: objdump  --start-address=0x00007fff5eb9a870 --stop-address=0x00007fff5eb9ab4c -l -d --no-show-raw -S -C /home/nanook/.debug/.build-id/51/54a08e7153b1deecc09259d1e970f9b67e1664
[...]
 Percent |      Source code & Disassembly of [vdso] for cycles:u
----------------------------------------------------------------
                             870: 4
                             876: 2
                             87f: 2
                             920: 2
                             93a: 2
                             967: 2
                             985: 1
                             988: 3
                             9a2: 2
                             9bb: 1
                             9c8: 6
                             9d6: 2
                             9d9: 4
                             a9d: 4
                             ab4: 2
                             ab8: 13
                             ac0: 1
                             ac7: 3763
                             ac9: 5
                          h->sum: 3821
         :
         :
[...]

So there's no disassembly output for the vdso using a perf tool build
from a vanilla 4.1 kernel.

If I run readelf on the generated ELF object, I see:

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0xffffffffff700700
  Start of program headers:          64 (bytes into file)
  Start of section headers:          3600 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         4
  Size of section headers:           64 (bytes)
  Number of section headers:         18
  Section header string table index: 17

Text section:

  [15] .text             PROGBITS         ffffffffff700700  00000700
       000000000000062d  0000000000000000  AX       0     0     16


So somehow the Image claims to be loaded at 0xffffffffff700000,
whilst perf's map is offset by 0x00007fff5eb9a000. This seems to be down
to the #define VDSO_PRELINK 0xffffffffff700000 in older kernels, but your
patch doesn't take that fixed address into account, so I don't see how
it's ever the right thing to do.

At least with my patch applied, recent kernels work. Without it, vdso
disassembly appears to be broken on all kernels for all architectures.

> > to be running on my box) but perf doesn't even detect the vdso there,
> > regardless of this patch.
> 
> Don't know what you mean about not detecting vdso

It just prints something like [perf.data.XXXX] instead of [vdso] -- probably
a separate bug.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/