llunak added a comment. In D86417#2239062 <https://reviews.llvm.org/D86417#2239062>, @JosephTremoulet wrote:
> and let me know how that goes? I don't have a linux system here to try it > on, but I have a feeling this may fix the problem you're seeing. Yes, it fixes my problem. However (if I'm getting it right), it fixes it by fixing only 'raise', but not 'abort'. If I do 'image show-unwind -n abort', I still get: eh_frame UnwindPlan: This UnwindPlan originally sourced from eh_frame CFI This UnwindPlan is sourced from the compiler: yes. This UnwindPlan is valid at all instruction locations: no. This UnwindPlan is for a trap handler function: no. ... eh_frame augmented UnwindPlan: This UnwindPlan originally sourced from eh_frame CFI This UnwindPlan is sourced from the compiler: yes. This UnwindPlan is valid at all instruction locations: no. This UnwindPlan is for a trap handler function: yes. The augmented unwind plan for abort is still for a trap handler (your patch affects "plus augmentation from assembly parsing", which is not this unwind plan). I don't know if this is a problem, but it looks suspicious to me, especially given that the eh_frame unwind plan is not for a trap handler. In D86417#2239062 <https://reviews.llvm.org/D86417#2239062>, @JosephTremoulet wrote: > From memory, I'd have expected that for `__restore_rt`, but not for `raise` > or `abort`. Can you dump the augmentation fields from the CIEs (or > instrument `FDEToUnwindPlan`) to verify we're getting that right? I made FDEToUnwindPlan() to print the augmentation string and it contains 'S' just once, when "GetSymbolOrFunctionName(m_sym_ctx)" in RegisterContextUnwind::InitializeNonZerothFrame() says "__restore_rt". So I assume that means the info in the binary is correct. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86417/new/ https://reviews.llvm.org/D86417 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
