-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: 17 June 2014 15:49
To: Nikolay Borisov
Cc: linux-arm-kernel at lists.infradead.org; jld at mozilla.com;
rric at kernel.org; a.p.zijlstra at chello.nl; Will Deacon;
sboyd at codeaurora.org; dave.long at linaro.org; u.kleine-
koenig at pengutronix.de; Dave P Martin
Subject: Re: [PATCH RESEND 0/7] Fix backtrace support in THUMB2 mode

On Fri, May 23, 2014 at 10:26:29AM +0100, Nikolay Borisov wrote:

quoted

Currently all the code which deals with backtrace support assumes

that R11

quoted

is the frame-pointer. While this is the case for ARM mode and is

explicitly

quoted

documented in the AAPCS, this is not the case for THUMB2 mode.

There is no official document requiring that R11 has to be the frame

pointer

quoted

and GCC uses R7 as FP and given that R7's usage is so intertwined

within GCC's

quoted

mechanics it is unlikely to change, so fixing backtrace in THUMB2

mode seems

quoted

in order.

This patch series rectifies the problem by first fixing the
thread_save_fp macro to reference the correct register. Furthermore,

there

quoted

a lot of repetetive sequences of code such as :

stackframe.fp = pt_regs->ARM_fp
stackframe.lr = pt_regs->ARM_lr

so introducing a function arm_get_current_stack_frame which both
hides this repetition and also utilizes teh frame_pointer(regs) macro
to reference the correct register depending on the mode.

Finally, change all the call sites so that they utilize the new

routine.

Can someone please explain to me what the point of this churn is?

During my testing with a THUMB2 kernel it turned out that no stacktrace
information was being printed when either magic-sysrq was used
or the 'ps -Al' command executed. The commit message of patch 8069/1 does
list those uses cases as failures resulting from this bug. 

Are you able to obtain backtrace support from a THUMB2 kernel using the 
the correct magic sysrq to dump the current threads stacktrace?

This thread started by Jed David also sheds some light on the issue: 
https://lkml.org/lkml/2013/7/12/469

Let's start with a summary of Thumb2 kernel building.  When a Thumb2
kernel is built, we may build it with or without frame pointers.  In
either case, we always require the unwinder.

When the unwinder is in use, we don't use the APCS backtracing support.
The APCS backtracing support makes use of the frame pointer (and
requires
frame pointer support.)

The unwinder, although it is given what would be in the frame pointer
register, never reads from this value - the only registers that the
unwinder cares about is the stack pointer (so it can read values off
the stack), LR (in case PC is zero) and the PC value itself (so it can
work out where in the unwind information to start the unwinding
process.

The unwinder does write to the FP entry, but this is not really used
for anything (in much the same way that it writes to the other
registers.)  It also prints the FP value in its debugging, though what
use that is can be argued.

So, although the code /may/ look weird, and not really conform to what
is expected, don't see any bug with the code as it stands today (with
the exception of one c_backtrace() call in arm_syscall, which should
probably be fixed - but that's an entirely separate problem.)

While we may deem that introducing arm_get_current_stackframe() is
a useful cleanup, that's all it should be...

Am I missing something?

--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up...
slowly
improving, and getting towards what was expected from it.