> On Jun 26, 2018, at 2:00 PM, Jim Ingham via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > >> * unwinding and backtrace generation > > Jason says this will be somewhat tricky to pull out of lldb. OTOH much of > the complexity of unwind is reconstructing all the non-volatile registers, > and if you don't care about values, you don't really need that. So some kind > of lightweight pc/sp only backtrace would be more appropriate, and probably > faster for your needs.
If it were me & performance were the utmost concern, and I had a restricted platform set that I needed to support where I can assume the presence of eh_frame and that it is trustworthy in prologue/epilogues, then I'd probably just write a simple Unwind/RegisterContext plugin pair that exclusively live off of that. If it's just stack walking, and we can assume no omit-frame-pointer code and we can assume the 0th function is always stopped in a non-prologue/epilogue location, then even simpler would be the old RegisterContextMacOSXFrameBackchain plugin would get you there. That's what we used before we had the modern unwind/registercontext plugin that we use today. It doesn't track spilled registers at all, it just looks for saved pc/framepointer values on the stack. A general problem with stopping the inferior process and examining things is that it is slow. Even if you use a NativeHost approach and get debugserver/lldb-server out of the equation, if you stop in a hot location it's very difficult to make this performant. We've prototyped things like this in the past and it was always far too slow. I don't know what your use case looks like, but I do worry about having one process controlling an inferior process in general for fast-turnaround data collection/experiments, it doesn't seem like the best way to go about it. > > Jim > >> >> >> >>> At the same time we think that in doing so we can break things up into more >>> granular pieces, ultimately exposing a larger testing surface and enabling >>> us to create exhaustive tests, giving LLDB more fine grained testing of >>> important subsystems. >> >> Are you thinking of the new utility as something that would naturally live >> in llvm/tools or as something that would live in the LLDB repository? >> I would rather put it under LLDB and then link LLDB against certain pieces >> in cases where that makes sense. >> >> >>> >>> A good example of this would be LLDB’s DWARF parsing code, which is more >>> featureful than LLVM’s but has kind of evolved in parallel. Sinking this >>> into LLVM would be one early target of such an effort, although over time >>> there would likely be more. >> >> As you are undoubtedly aware we've been carefully rearchitecting LLVM's >> DWARF parser over the last few years to eventually become featureful enough >> so that LLDB could use it, so any help on that front would be most welcome. >> As long as we are careful to not regress in performance/lazyness, features >> and fault-tolerance, deduplicating the implementations can only be good for >> LLVM and LLDB. >> >> Yea, this is the general idea. Has anyone actively been working on this >> specific effort recently? To my knowledge someone started and then never >> finished, but the efforts also never made it upstream, so my understanding >> is that it's a goal, but one that nobody has made significant headway on. >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
