Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753105AbbGQCJk (ORCPT ); Thu, 16 Jul 2015 22:09:40 -0400 Received: from mail-pd0-f182.google.com ([209.85.192.182]:36098 "EHLO mail-pd0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752016AbbGQCJj (ORCPT ); Thu, 16 Jul 2015 22:09:39 -0400 Message-ID: <55A863D6.7010408@linaro.org> Date: Fri, 17 Jul 2015 11:09:26 +0900 From: AKASHI Takahiro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Steven Rostedt , Mark Rutland CC: Jungseok Lee , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , "broonie@kernel.org" , "david.griego@linaro.org" , "olof@lixom.net" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [RFC 2/3] arm64: refactor save_stack_trace() References: <1436765375-7119-3-git-send-email-takahiro.akashi@linaro.org> <20150714093154.4d73e551@gandalf.local.home> <55A5A75A.1060401@linaro.org> <20150714225105.6c1e4f15@gandalf.local.home> <55A646EE.6030402@linaro.org> <20150715105536.42949ea9@gandalf.local.home> <20150715121337.3b31aa84@gandalf.local.home> <55A6FA82.9000901@linaro.org> <55A703F3.8050203@linaro.org> <20150716142834.GD28631@leverpostej> <20150716103445.3e94f0ee@gandalf.local.home> In-Reply-To: <20150716103445.3e94f0ee@gandalf.local.home> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1635 Lines: 44 On 07/16/2015 11:34 PM, Steven Rostedt wrote: > On Thu, 16 Jul 2015 15:28:34 +0100 > Mark Rutland wrote: > > >>> diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h >>> index c5534fa..868d6f1 100644 >>> --- a/arch/arm64/include/asm/ftrace.h >>> +++ b/arch/arm64/include/asm/ftrace.h >>> @@ -15,6 +15,7 @@ >>> >>> #define MCOUNT_ADDR ((unsigned long)_mcount) >>> #define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE >>> +#define FTRACE_STACK_FRAME_OFFSET 4 /* sync it up with stacktrace.c */ >> >> Is there any reason we couldn't have the arch code dump the stack depth >> for each function when it walks the stack to generate the stack trace? >> >> That means we can provide a more precise result (because we know the >> layour of our own stackframes), and we only need walk the stack once to >> do so. >> >> The downside is that we need a new function per-arch to do so. > > Or we make check_patch() a weak function, and let archs override it. I > can possibly break up the code a bit to have helper functions where > things are the same. Yeah, that is exactly what I meant in my cover letter[0/3] if the series of patches are not acceptable. -Takahiro AKASHI > I want x86 to be able to track irq stacks as well, but there's no way > to do that generically yet, so having arch specific functions has been > on my todo list. > > -- Steve > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/