summaryrefslogtreecommitdiffstats
path: root/arch/mn10300/kernel/kgdb.c
Commit message (Collapse)AuthorAgeFilesLines
* mn10300: Remove the architectureDavid Howells2018-03-091-502/+0
| | | | | | | | | | Remove the MN10300 arch as the hardware is defunct. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David Howells <dhowells@redhat.com> cc: Masahiro Yamada <yamada.masahiro@socionext.com> cc: linux-am33-list@redhat.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* Clarify naming of thread info/stack allocatorsLinus Torvalds2016-06-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've had the thread info allocated together with the thread stack for most architectures for a long time (since the thread_info was split off from the task struct), but that is about to change. But the patches that move the thread info to be off-stack (and a part of the task struct instead) made it clear how confused the allocator and freeing functions are. Because the common case was that we share an allocation with the thread stack and the thread_info, the two pointers were identical. That identity then meant that we would have things like ti = alloc_thread_info_node(tsk, node); ... tsk->stack = ti; which certainly _worked_ (since stack and thread_info have the same value), but is rather confusing: why are we assigning a thread_info to the stack? And if we move the thread_info away, the "confusing" code just gets to be entirely bogus. So remove all this confusion, and make it clear that we are doing the stack allocation by renaming and clarifying the function names to be about the stack. The fact that the thread_info then shares the allocation is an implementation detail, and not really about the allocation itself. This is a pure renaming and type fix: we pass in the same pointer, it's just that we clarify what the pointer means. The ia64 code that actually only has one single allocation (for all of task_struct, thread_info and kernel thread stack) now looks a bit odd, but since "tsk->stack" is actually not even used there, that oddity doesn't matter. It would be a separate thing to clean that up, I intentionally left the ia64 changes as a pure brute-force renaming and type change. Acked-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* mn10300: Use common threadinfo allocatorThomas Gleixner2012-05-081-2/+1
| | | | | | | | | Let the core code allocate and handle the kgdb cleanup with the arch_release_thread_info() function. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: David Howells <dhowells@redhat.com> Link: http://lkml.kernel.org/r/20120505150141.996582377@linutronix.de
* MN10300: Emulate single stepping in KGDB on MN10300David Howells2011-03-181-11/+311
| | | | | | | | | | | | | | | | | | | | | Emulate single stepping in KGDB on MN10300 by way of temporary breakpoint insertion. These breakpoints are never actually seen by KGDB, and will overlay KGDB's own breakpoints. The breakpoints are removed by switch_to() and reinstalled on switching back so that if preemption occurs, the preempting task doesn't hit them (though it will still hit KGDB's regular breakpoints). If KGDB is reentered for any reason, then the single step breakpoint is completely erased and must be set again by the debugger. We take advantage of the fact that KGDB will effectively halt all other CPUs whilst this CPU is single-stepping to avoid SMP problems. If the single-stepping task is preempted and killed without KGDB being reinvoked, then the breakpoint(s) will be cleared and KGDB will be jumped back into. Signed-off-by: David Howells <dhowells@redhat.com>
* MN10300: Use KGDBDavid Howells2011-03-181-0/+202
OpenPOWER on IntegriCloud