public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Torsten Duwe <duwe@lst.de>
To: Michael Ellerman <mpe@ellerman.id.au>, Jiri Kosina <jkosina@suse.cz>
Cc: Balbir Singh <bsingharora@gmail.com>,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	live-patching@vger.kernel.org
Subject: [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE
Date: Tue, 12 Dec 2017 12:39:12 +0100	[thread overview]
Message-ID: <20171212113912.GA1907@lst.de> (raw)
In-Reply-To: <39bb7180-1adf-4df6-c9ba-c6f92754767f@linux.vnet.ibm.com>

Hi all,

The "Power Architecture 64-Bit ELF V2 ABI" says in section 2.3.2.3:

[...] There are several rules that must be adhered to in order to ensure
reliable and consistent call chain backtracing:

* Before a function calls any other function, it shall establish its
  own stack frame, whose size shall be a multiple of 16 bytes.

 – In instances where a function’s prologue creates a stack frame, the
   back-chain word of the stack frame shall be updated atomically with
   the value of the stack pointer (r1) when a back chain is implemented.
   (This must be supported as default by all ELF V2 ABI-compliant
   environments.)
[...]
 – The function shall save the link register that contains its return
   address in the LR save doubleword of its caller’s stack frame before
   calling another function.

To me this sounds like the equivalent of HAVE_RELIABLE_STACKTRACE.
This patch may be unneccessarily limited to ppc64le, but OTOH the only
user of this flag so far is livepatching, which is only implemented on
PPCs with 64-LE, a.k.a. ELF ABI v2.

Signed-off-by: Torsten Duwe <duwe@suse.de>

---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c51e6ce42e7a..3e3a6ab2e089 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -218,6 +218,7 @@ config PPC
 	select HAVE_PERF_USER_STACK_DUMP
 	select HAVE_RCU_TABLE_FREE		if SMP
 	select HAVE_REGS_AND_STACK_ACCESS_API
+	select HAVE_RELIABLE_STACKTRACE		if PPC64 && CPU_LITTLE_ENDIAN
 	select HAVE_SYSCALL_TRACEPOINTS
 	select HAVE_VIRT_CPU_ACCOUNTING
 	select HAVE_IRQ_TIME_ACCOUNTING

       reply	other threads:[~2017-12-12 11:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20171004152516.25803-1-kamalesh@linux.vnet.ibm.com>
     [not found] ` <20171005124313.GA25100@lst.de>
     [not found]   ` <9f388c9a-8d74-865a-b113-f77322918b39@linux.vnet.ibm.com>
     [not found]     ` <20171017144733.GB2136@lst.de>
     [not found]       ` <95e6f942-88b7-0208-0eb0-2f5462aec410@linux.vnet.ibm.com>
     [not found]         ` <20171020120739.GA20306@lst.de>
     [not found]           ` <1508547548.5662.2.camel@gmail.com>
     [not found]             ` <39bb7180-1adf-4df6-c9ba-c6f92754767f@linux.vnet.ibm.com>
2017-12-12 11:39               ` Torsten Duwe [this message]
2017-12-12 12:12                 ` [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE Miroslav Benes
2017-12-12 13:02                   ` Torsten Duwe
2018-02-27 16:09                   ` [PATCH 2/2] ppc64le save_stack_trace_tsk_reliable (Was: HAVE_RELIABLE_STACKTRACE) Torsten Duwe
2018-03-08 21:43                     ` Balbir Singh
2018-03-09 15:54                       ` Torsten Duwe
2017-12-12 14:05                 ` [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE Josh Poimboeuf
2017-12-15  9:40                   ` Nicholas Piggin
2017-12-18  2:58                     ` Josh Poimboeuf
2017-12-18  3:39                       ` Balbir Singh
2017-12-18  4:01                         ` Josh Poimboeuf
2017-12-18  5:33                       ` Nicholas Piggin
2017-12-18 18:56                         ` Josh Poimboeuf
2017-12-19  2:46                           ` Nicholas Piggin
2017-12-19 11:28                           ` Torsten Duwe
2017-12-19 21:46                             ` Josh Poimboeuf
2017-12-21 12:10                               ` Michael Ellerman
2017-12-23  4:00                                 ` Josh Poimboeuf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171212113912.GA1907@lst.de \
    --to=duwe@lst.de \
    --cc=bsingharora@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox