Trapping function exit and return value

Hello,

With another debugger that I use, I’m able to set breakpoints on function exit and get the return value. (These are usually set automatically when the function is entered.)

This is useful for all sorts of things, but I haven’t seen an easy way to do this in LLDB. This is necessary for some tools that I’d like to build on top of LLDB.

A comment from Jim Ingham on Stackoverflow indicates that the return value portion of this isn’t robustly available yet:

http://stackoverflow.com/questions/20902019/inspect-the-return-value-of-a-function-in-lldb

I don’t want to force a return, just stop on the exit and read the value and be able to continue (and all preferably via the script API).

Did I miss something or is there a way? If not, any thoughts on how to best go about this?

Cheers,

  • Bruce

When you "step out" from a function, then the return value is available. But we don't track when "step over" happens to step out, and save the return value in that case. So if you are in charge of how you drive the debugger you can generally get this to work.

The issue for step in/over is harder because of the more complex way step over/in ends stepping. step out means leave this function and stop right away. Step over always runs to the end of line boundaries, so if the step over steps out of a function to the middle of a source line, we keep stepping to the end of the source line. This was the way gdb did things, and though there has been lots of debate in gdb about whether this is the right thing to do, lldb followed the gdb behavior because it was what folks were familiar with - to the extent that they noticed what was going on.

But that means you could step out of function A to B, then completing the line you landed on in B could cause you to step in and out of several other functions. So lldb has to get a way to store a vector of return values annotated in some useful way with where the return values come from. I plan to do this at some point (unless somebody beats me to it) because that would also be useful when you step over a line that contains some complex set of function calls. It would be great to be able to see all the values returned from that line. Gathering the return values is actually pretty easy, but figuring out how to annotate then in some useful way will take a little thought.

Jim