> On Nov 30, 2014, at 2:04 AM, René J.V. Bertin <rjvber...@gmail.com> wrote:
> What does TOT stand for? Top Of theTops ? :) > Sorry, head, top of tree, tip of tree. The trunk branch in svn. >> I have seen some edge cases on Mavericks (Mac OS X 10.10) where _sigtramp >> unwinding is not completely accurate. It's on my todo list to figure out >> what's going on there. > > Mavericks (10.9) or Yosemite (10.10)? Heh. I meant Yosemite 10.10. I noticed some odd behavior when looking at a backtrace with _sigtramp the other day on a 10.10 system. Basic backtracing looked correct but I thought one of the register save locations looked wrong. > It might be feasible though to replace lldb with a dedicated and very simple > "klldb" frontend. Is there a tutorial/example somewhere online that could > serve as a starting point? examples/python/process_events.py is the most common example we show to people. There's a C++ example of starting up a debug session, adding a breakpoint, hitting the breakpoint and doing a backtrace in test/api/multiple-debuggers/multi-process-driver.cpp. When I looked at this yesterday I didn't see an obvious way to attach to a process without having a Target -- and couldn't create a Target without an executable file. I need to go look at the API again but it wasn't super clear how to get started on your workflow where you're attaching to a PID. > A bit off-topic, but not irrelevant: if the lldb app is in fact just a > frontend, is there no one who has had the idea to create a sort of llvm-gdb > that couples the gdb user-interface to the lldb library? That would probably > also help with the rather severe lack of (free) GUIs to lldb on platforms > other than recent OS X versions. Most IDEs/GUIs talk to gdb with the "gdb MI" interface. It's a simple key-value/array/dictionary markup language that you can use when driving the debugger - kind of like JSON, but it was created before JSON so it's different. There is an lldb-mi front end being developed to support these IDE/GUIs although I don't know the state of that driver program. Emulating the full gdb command line input/output would be a lot of work to make it behave 100% the same. And some things would be very difficult to make the same -- for instance, gdb has a hand-written C/C++ parser to do expression evaluation (p 5+3). lldb uses clang to do this - which means we behave more faithfully to the language spec but some things that aren't legal C/C++ are very useful to do in a debugger. e.g. "p main + 5". I think adding an MI interface for lldb is a good idea -- but trying to emulate gdb's command line behavior would be a huge time sink for little benefit. (For an IDE, even better than using the MI interface would be to use lldb's native SB APIs to drive it. It's a much cleaner and richer interface between the debugger library and the front end. Hopefully some day we'll see the big IDEs like Eclipse use lldb by the SB API but until then, the MI is the easiest way to get them to work together) J _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
