[Crash-utility] Problem in bt for ARM64

[Dave Anderson]

Jan,

I went back to creating a machdep->machspec->user_eframe_offset value
to be able to account for both the 4.7 and the upcoming 4.14 pt_regs
changes:

  https://github.com/crash-utility/crash/commit/c975008e61121ef8785622c3bc26964da8fe0deb
 
Again, though, note that "bt" does not work with 4.14.

Thanks for the heads up,
  Dave


----- Original Message -----
> 
> 
> ----- 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