Community
Participate
Working Groups
Hi Eugene, I start to look at ARM64. I'm very new to ARM64 but it seems to me cpsr no longer exists and is replaced (partially) by pstate. In stack-crawl-a64.c, I still see some references to cpsr, which look wrong to me. Can I assume cpsr means pstate ? I don't think so... Thanks for providing me some infos on this. Are you planning to update the stack-crawl-a64.c to handle pstate ? Thanks ! Xavier.
From debugger point of view, cpsr is whatever is saved in spsr_el1 on EL switch, or in spsr_el2, spsr_el3, dspsr - depends on how debugging is implemented. It is common approach to call saved value cpsr, even though no such register exists in the hardware.
Hi Eugene, Thanks. Can you please clarify in stack-crawl-a64.c the role for REG_VAL_ADDR, REG_VAL_STACK, REG_VAL_OTHER and lazy loading of registers ? It's a little unclear to me. .o = 0 ==> Invalidate ? In such case, what does .v means ? .o = REG_VAL_STACK ==> Not used ? .o = REG_VAL_ADDR ==> Means an address, not read from memory / cache / manually .o = REG_VAL_OTHER ==> Read was done from cache / memory / manually Thanks !
(In reply to xavier pouyollon from comment #2) > Hi Eugene, > > Thanks. > > Can you please clarify in stack-crawl-a64.c the role for > REG_VAL_ADDR, REG_VAL_STACK, REG_VAL_OTHER and lazy loading of registers ? > > It's a little unclear to me. > > .o = 0 > ==> Invalidate ? In such case, what does .v means ? .v is invalid, register value unknown. > > .o = REG_VAL_STACK > ==> Not used ? Register value was found in a stack frame, and, potentially, can represent return address. Helps to resolve certain types of ambiguity. Currently not used for A64. > > .o = REG_VAL_ADDR > ==> Means an address, not read from memory / cache / manually .v is address of the register value. Lazy reading greatly improves performance when memory access is slow, e.g. over JTAG. > > .o = REG_VAL_OTHER > ==> Read was done from cache / memory / manually .v is valid register value.
Great ! Thanks !
