aboutsummaryrefslogtreecommitdiff
path: root/lldb/scripts/Python/modify-python-lldb.py
diff options
context:
space:
mode:
authorGreg Clayton <gclayton@apple.com>2011-09-29 23:41:34 +0000
committerGreg Clayton <gclayton@apple.com>2011-09-29 23:41:34 +0000
commit6c7f56192fa6e689ef14d32e43a785de5692e9c0 (patch)
tree8846a2853b68e0c5f59e76751ef68d46093cac0c /lldb/scripts/Python/modify-python-lldb.py
parenta3e7ffdae80e06f88191be8ec80d7d21f158ac54 (diff)
downloadllvm-6c7f56192fa6e689ef14d32e43a785de5692e9c0.zip
llvm-6c7f56192fa6e689ef14d32e43a785de5692e9c0.tar.gz
llvm-6c7f56192fa6e689ef14d32e43a785de5692e9c0.tar.bz2
Fixed an issue where a lexical block or inlined function might have bad debug
information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
Diffstat (limited to 'lldb/scripts/Python/modify-python-lldb.py')
0 files changed, 0 insertions, 0 deletions