diff options
author | Greg Clayton <gclayton@apple.com> | 2011-09-29 23:41:34 +0000 |
---|---|---|
committer | Greg Clayton <gclayton@apple.com> | 2011-09-29 23:41:34 +0000 |
commit | 6c7f56192fa6e689ef14d32e43a785de5692e9c0 (patch) | |
tree | 8846a2853b68e0c5f59e76751ef68d46093cac0c /lldb/scripts/Python/modify-python-lldb.py | |
parent | a3e7ffdae80e06f88191be8ec80d7d21f158ac54 (diff) | |
download | llvm-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