On Tue, Dec 3, 2013 at 7:08 PM, Will Deacon [off-list ref] wrote:

On Tue, Dec 03, 2013 at 11:21:39AM +0000, Will Deacon wrote:

quoted

On Tue, Dec 03, 2013 at 10:16:37AM +0000, Mark Rutland wrote:

quoted

I think that there's a slight problem with this on BE systems.

[...]

quoted

On Sat, Nov 30, 2013 at 06:32:26AM +0000, vijay.kilari at gmail.com wrote:

quoted

+       { "pstate", 4, offsetof(struct pt_regs, pstate)},

As pt_regs::pstate is a u64, we're only describing half of the field
here (to match GDB's expectations). While we happen to get the half
we're interested in on an LE system, on a BE system this will point at
the zeroed half.

Yup, I think you're right. It's almost as if this hasn't been tested on a BE
system.

Given that a large proportion of this CC list *do* actually care about BE,
I'd like to see a tested-by from one of them before this gets merged. I'm
pretty sure GDB has a testsuite which might be of some use.

Having said that, our ptrace interface (built around regsets) treats pstate
as 64-bit, so we should do the same thing for kgdb and let GDB work out
which bits it's interested in.

So: make pstate 8 bytes and test/fix GDB to deal with that (like it should
do for userspace already).

I have tested with BE & LE. it works fine except displaying 'pstate' contents
in BE is wrong

If I change pstate offset as below, it works

#ifdef __AARCH64EB__
        { "pstate", 4, offsetof(struct pt_regs, pstate) + 4},
#else
        { "pstate", 4, offsetof(struct pt_regs, pstate)},
#endif

I am checking with tool chain guy to patch GDB to make pstate as 8 bytes.
After that, I will re-send the patch series

Will