labath added a comment. Thank you for looking at this. My response is below.
In https://reviews.llvm.org/D32022#733223, @jasonmolenda wrote: > Hi Pavel, I'd document the new flag in include/lldb/Core/Address.h where we > have documentation for the other flags being used. > > It seems like we're fixing this a little indirectly, and I'm not sure it's > the best approach. I want to make sure I understand the situation correctly. > > Say we have an object file with three sections > > s1 0..99 (offset 0, size 100) > s2 100..199 (offset 100, size 100) > s3 200.299 (offset 200, size 100) > > We have a noreturn function whose last instruction ends on the last byte of > s2, so the saved return address is offset 200. Your change makes it so that > when we say "is 200 contained within 100..199", we will say yes, it is. This > gets us the correct Section for our symbol context and when we back up the pc > value by one (the "decr_pc_and_recompute_addr_range = true" bit in > RegisterContextLLDB::InitializeNonZerothFrame) so when we back up the offset > within the section by 1, we're good. The reason that `decr_pc_and_recompute_addr_range` is not working is because we don't find any section (or module) at all. In the object file you mention above, this would correspond to having a noreturn function at the end of `s3`, and then the space after `s3` being empty. In this case we don't even reach the `decr_pc_and_recompute_addr_range` part, because we abort due to a missing module. In my first version of this patch did something different -- I modified `RegisterContextLLDB` to retry the module search by decrementing the pc by one if the original search did not find any module. However, that did not seem completely clean either, as I had to do the same dance twice (`StackFrame::GetFrameCodeAddress` needed to do the same dance as well to display the symbol name correctly). I can go back to that implementation if you think that is better. > I have access to a linux machine so I can play with this myself, but it will > take me a while to set up lldb on that system, could you let me know if you > looked at this approach? I know RegisterContextLLDB is complicated and it's > easy to miss things - or it may be that you tried this approach and it didn't > look possible. (and I haven't had to touch this code in a few years so I > may have forgotten about some "new Section is the same as the old Section" > sanity check or something in there... I don't see it right now, but I may > have missed it.) You don't need a linux machine to debug this -- you should be able to open the core file in the test from any system (last time I tried, I had problems downloading binary files from phabricator, so I am going to also send them to you directly, just in case). You could probably also create a darwin executable reproducing this using assembly similar to the one in the test. ================ Comment at: source/Plugins/Process/Utility/RegisterContextLLDB.cpp:339 ModuleSP pc_module_sp(m_current_pc.GetModule()); if (!m_current_pc.IsValid() || !pc_module_sp) { UnwindLogMsg("using architectural default unwind method"); ---------------- Here we don't get a valid module and we abort the search. https://reviews.llvm.org/D32022 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
