lldb/llvm debug info for methods

Subprojects LLDB
1

With http://pastebin.com/Rzwa5Bx7 why does LLDB show:
___lldb_unnamed_function1$$tempexee10f7bb9b9eb4728a5d78008878bdccd-ConsoleApplication104

in the callstack for the @async and @"<main>b__0" methods?

all 3 functions have a debug info record
and the main() method works fine, I can step through it etc.
async/@"<main>b__0" i cannot, yet they have debug info records associated.

2

I'm not sure what you mean when you can't step through a method. You might want to show an example from an lldb debug session where something is not working as you expected.

For the best behavior unwinding the stack, lldb needs to know the start addresses of every function in a file. Often times a file can get stripped of some of its (non-exported) symbols -- but in Mach-O binaries there is a separate section (LC_FUNCTION_STARTS) which doesn't get stripped out and provides the start address of every function in the file. This information can also be gotten from the eh_frame unwind information if that is present. lldb uses these sources of information to supplement the symbol table and add these "unnamed_function" symbols when it reads in the object file.

J

3

Op 21-3-2013 20:16, Jason Molenda schreef:

I'm not sure what you mean when you can't step through a method. You

might want to show an example from an lldb debug session where something
is not working as you expected.

For the best behavior unwinding the stack, lldb needs to know the

start addresses of every function in a file. Often times a file can get
stripped of some of its (non-exported) symbols -- but in Mach-O binaries
there is a separate section (LC_FUNCTION_STARTS) which doesn't get
stripped out and provides the start address of every function in the
file. This information can also be gotten from the eh_frame unwind
information if that is present. lldb uses these sources of information
to supplement the symbol table and add these "unnamed_function" symbols
when it reads in the object file.

Thanks for the suggestion. It ended up simply being that "private" didn't work at all with the debugger. Switched to "internal" linkage (after a suggestion on LLVM Project) and everything works as expected.

Thanks!