Re: [Crash-utility] Problem in bt for ARM64
----- 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