lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 27 Jun 2014 16:53:51 +0200
From:	Jean Pihet <jean.pihet@...aro.org>
To:	Will Deacon <will.deacon@....com>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	Sneha Priya <sneha.cse@...mail.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ARM: perf: allow tracing with kernel tracepoints events

Hi Will,

On 26 June 2014 11:00, Will Deacon <will.deacon@....com> wrote:
> On Wed, Jun 25, 2014 at 03:54:14PM +0100, Jean Pihet wrote:
>> Hi Will,
>
> Hello,
>
>> On 25 June 2014 11:01, Will Deacon <will.deacon@....com> wrote:
>> > On Fri, Jun 20, 2014 at 09:10:35AM +0100, Jean Pihet wrote:
>> >> On 18 June 2014 14:53, Will Deacon <will.deacon@....com> wrote:
>> >> > On Tue, Jun 17, 2014 at 06:11:05PM +0100, Jean Pihet wrote:
>> >> >> Tested with perf record and tracepoints filtering (-e <tracepoint>), with
>> >> >> unwinding using fp (--call-graph fp) and dwarf info (--call-graph dwarf).
>> >> >
>> >> > Whilst the old ACPS unwinding only needs PC, FP and SP, is this definitely
>> >> > true for exidx and DWARF-based unwinding? Given that libunwind ends up
>> >> > running a state machine for the latter, can we guarantee that we won't hit
>> >> > instructions that require access to other general purpose registers?
>> >> Yes. dwarf unwinding does not need anything extra. Once seeded all the
>> >> rest is extracted from the dwarf trace info.
>> >
>> > Ok, but what if the LR isn't saved on the stack, for example? What if the
>> > code you're trying to unwind is hand-written assembly annotated with CFI
>> > directives?
>> Then in that case the unwinding is not possible unless the
>> hand-crafted asm is compatible with the requested unwinding method
>> (fp, dwarf etc.). Do you expect problems there, if so can you give
>> more details?
>
> To use a readily available AArch64 example, take a look at
> __kernel_gettimeofday in arch/arm64/kernel/vdso/gettimeofday.S
>
> It starts by moving the link register into x2, so that it can later call
> __do_get_tspec without clobbering it. Furthermore, it doesn't make use of
> the stack at all.
>
> How can you unwind that using your current code?
That is interesting. In that case that particular function will not be
seen in the call chain since lr, fp are the ones from the caller. I
did not try on a real case, it would be nice to try it out, I can do
that as soon as I am back on ARM64.

Note: I was debugging a deadlock in perf doing call chain unwinding
and tracepoint triggering. A new patch set is on its way.

Thx & regards,
Jean

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ