summaryrefslogtreecommitdiffstats
path: root/lldb/tools/lldb-perf/lib/Xcode.cpp
diff options
context:
space:
mode:
authorJason Molenda <jmolenda@apple.com>2013-03-21 03:36:01 +0000
committerJason Molenda <jmolenda@apple.com>2013-03-21 03:36:01 +0000
commit5635f77a99ff796af8d4ff595e8ad1bb2ae2bcfb (patch)
tree9d4743ed71c8b3cd7ae06d74f419656fc8497e67 /lldb/tools/lldb-perf/lib/Xcode.cpp
parentef0d2142ba3cad17ed09130f98b6efe2e00b2aa2 (diff)
downloadbcm5719-llvm-5635f77a99ff796af8d4ff595e8ad1bb2ae2bcfb.tar.gz
bcm5719-llvm-5635f77a99ff796af8d4ff595e8ad1bb2ae2bcfb.zip
Add a new method GetFunctionAddressAndSizeVector to DWARFCallFrameInfo.
This returns a vector of <file address, size> entries for all of the functions in the module that have an eh_frame FDE. Update ObjectFileMachO to use the eh_frame FDE function addresses if the LC_FUNCTION_STARTS section is missing, to fill in the start addresses of any symbols that have been stripped from the binary. Generally speaking, lldb works best if it knows the actual start address of every function in a module - it's especially important for unwinding, where lldb inspects the instructions in the prologue of the function. In a stripped binary, it is deprived of this information and it reduces the quality of our unwinds and saved register retrieval. Other ObjectFile users may want to use the function addresses from DWARFCallFrameInfo to fill in any stripped symbols like ObjectFileMachO does already. <rdar://problem/13365659> llvm-svn: 177624
Diffstat (limited to 'lldb/tools/lldb-perf/lib/Xcode.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud