Subject: [PATCH 0/2] microblaze: add stack unwinder
From: "Steven J. Magnani" <steve@digidescorp.com>
Reply-To: steve@digidescorp.com
To: microblaze-uclinux@itee.uq.edu.au, Michal Simek <monstr@monstr.eu>
Cc: linux-kernel@vger.kernel.org
Content-Type: text/plain
Organization: Digital Design Corporation
Date: Tue, 13 Apr 2010 23:53:46 -0500
Message-Id: <1271220827.2897.23.camel@iscandar.digidescorp.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2149
Lines: 42

This has been baking for awhile, I think it's ready for prime time. I've
beat on it in a noMMU kernel for awhile - backtracetest module,
kmemleak, dump_stack() in a number of different situations - all look
good. Thanks to Paul Mundt for initial advice on this feature.

I don't have MMU hardware or the ability to build a MMU kernel, so all
I've done there is check for gross compile errors. The MMU kernel
handles kernel stacks differently, which isn't an issue except in the
trap handlers (interrupt, syscall, etc.). This patch should work for MMU
kernels, but they won't trace back beyond a system trap. The intent is
to provide hooks for someone to add that capability later.

The key feature of the design is a search backwards from each return
address for the instruction that creates a stack frame.
CONFIG_FRAME_POINTER causes Microblaze gcc to use r19 as a frame
pointer, but because previous frame pointers are not stored in a
consistent location within each frame, it's not possible to avoid some
sort of search to determine frame size. (Side note, since
-fno-omit-frame-pointer isn't useful for Microblaze, it would be nice if
Microblaze could "opt-out" of FRAME_POINTER when selecting
FUNCTION_TRACER).

A brute-force search was chosen over a kallsyms-assisted search (as used
in the sh architecture) to avoid going off the rails in cases where
kallsyms chooses the closest global address instead of the true (local)
function address. Obviously there's an accuracy/speed tradeoff, but
under an assumption that most functions are reasonably-sized and most
backtraces are not performed in time-critical paths, this should be OK.

Happy unwinding,
------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"

 #include <standard.disclaimer>


--
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/