diff options
author | mseaborn@chromium.org <mseaborn@chromium.org> | 2014-12-03 20:39:55 +0000 |
---|---|---|
committer | mseaborn@chromium.org <mseaborn@chromium.org> | 2014-12-03 20:39:55 +0000 |
commit | 10baadae400ca0a06acd309f42b20972521cf923 (patch) | |
tree | 53382034b7bc5afcd47045529ccdff18aa98bf4f /autotools | |
parent | Microdumps: support aarch64 and lib mapping from APK (diff) | |
download | breakpad-10baadae400ca0a06acd309f42b20972521cf923.tar.xz |
dump_syms: Fix handling of DW_FORM_ref_addr to work with DWARF 4
Previously, dump_syms did not handle DW_FORM_ref_addr if it appeared
in DWARF 4 debugging info.
Also fix a DW_FORM_ref_addr case so that it doesn't fall through to
the next switch case when assertions are disabled and the DWARF
version isn't recognised.
The following steps will reproduce the problem when using LLVM 3.4:
cat <<END >example1.c
int main() { return 0; }
END
cat <<END >example2.c
void foo(int x) {}
END
clang -emit-llvm -g -c example1.c -o example1.bc
clang -emit-llvm -g -c example2.c -o example2.bc
llvm-link-3.4 example1.bc example2.bc -o combined.bc
clang combined.bc -o executable
./google-breakpad/build/src/tools/linux/dump_syms/dump_syms executable
When using LLVM bitcode linking in this way, LLVM's backend generates
partially-merged DWARF debugging info in which some of the references
to the "int" type go via "DW_FORM_ref_addr". Since PNaCl uses LLVM
bitcode linking, this dump_syms failure occurs with nexes produced by
the PNaCl toolchain.
BUG= https://code.google.com/p/chromium/issues/detail?id=416368
TEST= see above
R=mark@chromium.org, mcgrathr@chromium.org
Review URL: https://breakpad.appspot.com/5744002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1408 4c0a9323-5329-0410-9bdc-e9ce6186880e
Diffstat (limited to 'autotools')
0 files changed, 0 insertions, 0 deletions