----- Original Message -----
>
> ----- Original Message -----
> > Ok. I have seen this change in the pt_regs struct before but did not connect
> > it to this problem. I see these new field in pt_regs in earlier kernel
> > versions than 4.7, but it is probably backports. It really does not matter
> > for the solution of the problem. The following change works for me:
> > Change:
> > #define USER_EFRAME_OFFSET (304)
> > to:
> > #define USER_EFRAME_OFFSET (STRUCT_SIZE("pt_regs") + 16)
> >
> > Then you might want to avoid the recalculation of the struct size. I think
> > your patch does the same thing.
>
> Yeah, but doing it your way makes better sense. In fact, I see that there's
> another commit coming down the pike in 4.14-rc1 that changes the size yet
> again:
>
> diff --git a/arch/arm64/include/asm/ptrace.h
> b/arch/arm64/include/asm/ptrace.h
> index 11403fd..ee72aa9 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -119,6 +119,7 @@ struct pt_regs {
> u64 syscallno;
> u64 orig_addr_limit;
> u64 unused; // maintain 16 byte alignment
> + u64 stackframe[2];
> };
>
> Thanks,
> Dave
As it turns out, neither patch works for 4.14 with the kernel commit above.
The stackframe[2] addition essentially accounts for the 16 bytes at the
top of the stack.
The pt_regs structure in 4.14 is 320 bytes:
crash> pt_regs
struct pt_regs {
union {
struct user_pt_regs user_regs;
struct {
u64 regs[31];
u64 sp;
u64 pc;
u64 pstate;
};
};
u64 orig_x0;
s32 syscallno;
u32 unused2;
u64 orig_addr_limit;
u64 unused;
u64 stackframe[2];
}
SIZE: 320
crash>
So for example, taking a user-space task with a stacktop address of
ffff00000807c000:
crash> eval ffff00000807c000 - 320
hexadecimal: ffff00000807bec0
decimal: 18446462598867566272 (-281474841985344)
octal: 1777770000001001737300
binary: 1111111111111111000000000000000000001000000001111011111011000000
crash>
Here is the pt_regs:
crash> pt_regs ffff00000807bec0 -x
struct pt_regs {
{
user_regs = {
regs = {0x4, 0xffffe4ef4db0, 0x25, 0xffffffffffffffff, 0x0, 0x8,
0xffffffbb, 0x0, 0x16, 0x74, 0x65, 0x67, 0x10, 0x0, 0x1bb58f1f76129a, 0xce,
0xaaaaab21c660, 0xffffab4d35a8, 0xaaaaab1a0aa8, 0x4, 0x0, 0xffffe4ef4db0, 0x0,
0x1, 0xaaaaab180778, 0xaaaaab21c000, 0xaaaaab1803f0, 0xaaaaab21c000,
0xffffe4ef52b8, 0xffffe4ef4d70, 0xffffab4d3830},
sp = 0xffffe4ef4d70,
pc = 0xffffab4d385c,
pstate = 0x80000000
},
{
regs = {0x4, 0xffffe4ef4db0, 0x25, 0xffffffffffffffff, 0x0, 0x8,
0xffffffbb, 0x0, 0x16, 0x74, 0x65, 0x67, 0x10, 0x0, 0x1bb58f1f76129a, 0xce,
0xaaaaab21c660, 0xffffab4d35a8, 0xaaaaab1a0aa8, 0x4, 0x0, 0xffffe4ef4db0, 0x0,
0x1, 0xaaaaab180778, 0xaaaaab21c000, 0xaaaaab1803f0, 0xaaaaab21c000,
0xffffe4ef52b8, 0xffffe4ef4d70, 0xffffab4d3830},
sp = 0xffffe4ef4d70,
pc = 0xffffab4d385c,
pstate = 0x80000000
}
},
orig_x0 = 0x4,
syscallno = 0x16,
unused2 = 0x0,
orig_addr_limit = 0x0,
unused = 0x0,
stackframe = {0x0, 0x0}
}
crash>
So for backwards compatibility, it will be necessary to look for the
new stackframe[2] field.
Unfortunately there have been some other significant changes to the
unwind code in 4.14, and because of them, "bt" fails completely.
Dave
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
