aboutsummaryrefslogtreecommitdiffstats
path: root/include/asm-m32r/ptrace.h
Commit message (Collapse)AuthorAge
* Fix 'make headers_check' on m32rDavid Woodhouse2006-09-21
| | | | | | | | | | | > asm-m32r/page.h requires asm-generic/memory_model.h, which does not exist > asm-m32r/ptrace.h requires asm/m32r.h, which does not exist > asm-m32r/signal.h requires linux/linkage.h, which does not exist > asm-m32r/unistd.h requires asm/syscall.h, which does not exist > asm-m32r/user.h requires asm/processor.h, which does not exist Signed-off-by: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* Don't include linux/config.h from anywhere else in include/David Woodhouse2006-04-26
| | | | Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* [PATCH] m32r: Fix pt_regs for !COFNIG_ISA_DSP_LEVEL2 targetHirokazu Takata2006-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This modification is required to fix debugging function for m32r targets with !CONFIG_ISA_DSP_LEVEL2, by unifying 'struct pt_regs' and 'struct sigcontext' size for all M32R ISA. Some m32r processor core with !CONFIG_ISA_DSP_LEVEL2 configuration has only single accumulator a0 (ex. VDEC2 core, M32102 core, etc.), the others with CONFIG_ISA_DSP_LEVEL2 has two accumulators, a0 and a1. This means there are two variations of thread context. So far, we reduced and changed stackframe size at a syscall for their context size. However, this causes a problem that a GDB for processors with CONFIG_ISA_DSP_LEVEL2 cannot be used for processors with !CONFIG_ISA_DSP_LEVEL2. From the viewpoint of GDB support, we should reduce such variation of stackframe size for simplicity. In this patch, dummy members are added to 'struct pt_regs' and 'struct sigcontext' to adjust their size for !CONFIG_ISA_DSP_LEVEL2. This modification is also a one step for a GDB update in future. Currently, on the m32r, GDB can access process's context by using ptrace functions in a simple way of register by register access. By unifying stackframe size, we have a possibility to make use of ptrace functions of not only a single register access but also block register access, PTRACE_{GETREGS,PUTREGS}. However, for this purpose, we might have to modify stackframe structure some more; for example, PSW (processor status word) register should be pre-processed before pushing to stack at a syscall, and so on. In this case, we must update carefully both kernel and GDB at a time... Signed-off-by: Hayato Fujiwara <fujiwara@linux-m32r.org> Signed-off-by: Hirokazu Takata <takata@linux-m32r.org> Cc: Kei Sakamoto <ksakamot@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] m32r: task_pt_regs(), task_stack_page(), task_thread_info()Al Viro2006-01-12
| | | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] consolidate sys_ptrace()Christoph Hellwig2005-11-07
| | | | | | | | | | | | | | | | | | | | | | The sys_ptrace boilerplate code (everything outside the big switch statement for the arch-specific requests) is shared by most architectures. This patch moves it to kernel/ptrace.c and leaves the arch-specific code as arch_ptrace. Some architectures have a too different ptrace so we have to exclude them. They continue to keep their implementations. For sh64 I had to add a sh64_ptrace wrapper because it does some initialization on the first call. For um I removed an ifdefed SUBARCH_PTRACE_SPECIAL block, but SUBARCH_PTRACE_SPECIAL isn't defined anywhere in the tree. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Paul Mackerras <paulus@samba.org> Acked-by: Ralf Baechle <ralf@linux-mips.org> Acked-By: David Howells <dhowells@redhat.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!