On 27/01/2020 19:43, Alexander Zhang via lldb-dev wrote: > Hi, > > Thanks for pointing me towards stack unwinding. I don't have debug > information much of the time, so I'm depending on the architecture rules > for backtracing. A look at the mips ABI plugin shows it uses dwarf > register numbers to get the register values it needs, and I wasn't > including them in my qRegisterInfo responses. After fixing this, step > over and step out appear to work correctly, which is a great help. > > However, backtraces only show 2 frames with the current pc and ra > values, no matter where I am, so it seems there's some problem getting > stack frame info from the actual stack. I've attached an unwind log from > running bt inside a function that should have a deeper backtrace. The > afa value of 0xffffffffffffffff looks suspicious to me, but I don't > really understand where it comes from. The frame before 0x8002ee70 > should, I think, be 0x80026a6c, as that's the pc after stepping out twice. > > Thanks, > Alexander >
Hi Alexander, I am pretty sure the AFA is a red herring and you needn't worry about it. It is only used in some very specific circumstances, when a function realigns the stack pointer (e.g. when you have a over-aligned local variable), and only on x86 I believe. Everyone else gets a 0xfff...f value, and that's fine. pl _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
