[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACM3HyH8P=u9pR0sa2besxsgDN5TUKg_7utLJTwL+hu8Wv48ow@mail.gmail.com>
Date: Sat, 10 Sep 2011 08:42:26 +0200
From: Jonas Bonn <jonas.bonn@...il.com>
To: "Linas Vepstas (Code Aurora)" <linas@...eaurora.org>
Cc: Richard Kuo <rkuo@...eaurora.org>, linux-arch@...r.kernel.org,
linux-hexagon@...r.kernel.org, linux-kernel@...r.kernel.org,
arnd@...db.de
Subject: Re: [patch v3 19/36] Hexagon: Add ptrace support
On 9 September 2011 23:18, Linas Vepstas (Code Aurora)
<linas@...eaurora.org> wrote:
> On Fri, Sep 09, 2011 at 10:15:20PM +0200, Jonas Bonn wrote:
>>
>> That said, I don't think gdbserver has been updated to use
>> GETREGSET/SETREGSET. This is a bit like the uClibc/glibc issue,
>
> Some dumb questions then: I notice that a few arches declare
> struct user_regs_struct in glibc, most of the others in the
> kernel. If I were to make pt_regs completely kernel-private,
> then I really do need to have struct user_regs_struct declared
> the kernel headers, right?
Yes, on OpenRISC we declare it in ptrace.h (see
arch/openrisc/include/asm/ptrace.h).
>
> Putting a printk into case PTRACE_POKEUSR seemed to show that
> gdb was using this (and was somehow mis-numbering the registers
> ... sigh.) Are you saying that the default should handle this?
I'm really not an expert on GDB, but I believe it can use either the
PEEK/POKE functions to access regs, or it can use GET/SETREGS; it's an
architecture-dependent configuration. I think the second variant can
be easily modified to become GET/SETREGSET instead, and the PEEK/POKE
variant wouldn't be needed at all.
/Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists