On 26/06/2015 5:58 p.m., Will Deacon wrote:
(CC'ing Andy, since the removal of VDSO_PRELINK is user-visible here)
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 <n...@tbricks.com>
Cc: Adrian Hunter <adrian.hun...@intel.com>
Cc: Namhyung Kim <namhy...@kernel.org>
Reported-by: Kristina Martsenko <kristina.martse...@arm.com>
Signed-off-by: Will Deacon <will.dea...@arm.com>
---

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

Annotation is broken but the symbol gets resolved.

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

Reply via email to