[Lldb-commits] [PATCH] D32022: Fix backtrace of noreturn functions situated at the end of a module

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Apr 21 02:04:40 PDT 2017


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





More information about the lldb-commits mailing list