maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/DebugInfo/X86/dwarfdump-debug-loc-error-c...

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

75 lines
2.7 KiB
ArmAsm
Raw Normal View History

DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
# RUN: llvm-mc %s -filetype obj -triple x86_64-pc-linux --defsym CASE1=0 -o %t1.o
Reapply "llvm-dwarfdump: Report errors when failing to parse loclist/debug_loc entries"" Originally committed as 416fa7720e30750939c53935051c6c750dfad2c2 Reverted (due to buildbot failure - breaking lldb) in 7a45aeacf3a23449039ef2efcf476995ae1c7007. I still can't seem to build lldb locally, but Pavel Labath has kindly provided a potential fix to preserve the old behavior in lldb by registering a simple recoverable error handler there that prints to the desired stream in lldb, rather than stderr.
2020-04-15 05:21:33 +08:00
# RUN: not llvm-dwarfdump -debug-loc %t1.o 2>&1 | FileCheck %s
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
# RUN: llvm-mc %s -filetype obj -triple x86_64-pc-linux --defsym CASE2=0 -o %t2.o
Reapply "llvm-dwarfdump: Report errors when failing to parse loclist/debug_loc entries"" Originally committed as 416fa7720e30750939c53935051c6c750dfad2c2 Reverted (due to buildbot failure - breaking lldb) in 7a45aeacf3a23449039ef2efcf476995ae1c7007. I still can't seem to build lldb locally, but Pavel Labath has kindly provided a potential fix to preserve the old behavior in lldb by registering a simple recoverable error handler there that prints to the desired stream in lldb, rather than stderr.
2020-04-15 05:21:33 +08:00
# RUN: not llvm-dwarfdump -debug-loc %t2.o 2>&1 | FileCheck %s
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
# RUN: llvm-mc %s -filetype obj -triple x86_64-pc-linux --defsym CASE3=0 -o %t3.o
Reapply "llvm-dwarfdump: Report errors when failing to parse loclist/debug_loc entries"" Originally committed as 416fa7720e30750939c53935051c6c750dfad2c2 Reverted (due to buildbot failure - breaking lldb) in 7a45aeacf3a23449039ef2efcf476995ae1c7007. I still can't seem to build lldb locally, but Pavel Labath has kindly provided a potential fix to preserve the old behavior in lldb by registering a simple recoverable error handler there that prints to the desired stream in lldb, rather than stderr.
2020-04-15 05:21:33 +08:00
# RUN: not llvm-dwarfdump -debug-loc %t3.o 2>&1 | FileCheck %s
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
# RUN: llvm-mc %s -filetype obj -triple x86_64-pc-linux --defsym CASE4=0 -o %t4.o
Reapply "llvm-dwarfdump: Report errors when failing to parse loclist/debug_loc entries"" Originally committed as 416fa7720e30750939c53935051c6c750dfad2c2 Reverted (due to buildbot failure - breaking lldb) in 7a45aeacf3a23449039ef2efcf476995ae1c7007. I still can't seem to build lldb locally, but Pavel Labath has kindly provided a potential fix to preserve the old behavior in lldb by registering a simple recoverable error handler there that prints to the desired stream in lldb, rather than stderr.
2020-04-15 05:21:33 +08:00
# RUN: not llvm-dwarfdump -debug-loc %t4.o 2>&1 | FileCheck %s
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
# RUN: llvm-mc %s -filetype obj -triple x86_64-pc-linux --defsym CASE5=0 -o %t5.o
Reapply "llvm-dwarfdump: Report errors when failing to parse loclist/debug_loc entries"" Originally committed as 416fa7720e30750939c53935051c6c750dfad2c2 Reverted (due to buildbot failure - breaking lldb) in 7a45aeacf3a23449039ef2efcf476995ae1c7007. I still can't seem to build lldb locally, but Pavel Labath has kindly provided a potential fix to preserve the old behavior in lldb by registering a simple recoverable error handler there that prints to the desired stream in lldb, rather than stderr.
2020-04-15 05:21:33 +08:00
# RUN: not llvm-dwarfdump -debug-loc %t5.o 2>&1 | FileCheck %s
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
# RUN: llvm-mc %s -filetype obj -triple x86_64-pc-linux --defsym CASE6=0 -o %t6.o
Reapply "llvm-dwarfdump: Report errors when failing to parse loclist/debug_loc entries"" Originally committed as 416fa7720e30750939c53935051c6c750dfad2c2 Reverted (due to buildbot failure - breaking lldb) in 7a45aeacf3a23449039ef2efcf476995ae1c7007. I still can't seem to build lldb locally, but Pavel Labath has kindly provided a potential fix to preserve the old behavior in lldb by registering a simple recoverable error handler there that prints to the desired stream in lldb, rather than stderr.
2020-04-15 05:21:33 +08:00
# RUN: not llvm-dwarfdump -debug-loc %t6.o 2>&1 | FileCheck %s
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
MCRegisterInfo: Merge getLLVMRegNum and getLLVMRegNumFromEH Summary: The functions different in two ways: - getLLVMRegNum could return both "eh" and "other" dwarf register numbers, while getLLVMRegNumFromEH only returned the "eh" number. - getLLVMRegNum asserted if the register was not found, while the second function returned -1. The second distinction was pretty important, but it was very hard to infer that from the function name. Aditionally, for the use case of dumping dwarf expressions, we needed a function which can work with both kinds of number, but does not assert. This patch solves both of these issues by merging the two functions into one, returning an Optional<unsigned> value. While the same thing could be achieved by adding an "IsEH" argument to the (renamed) getLLVMRegNumFromEH function, it seemed better to avoid the confusion of two functions and put the choice of asserting into the hands of the caller -- if he checks the Optional value, he can safely process "untrusted" input, and if he blindly dereferences the Optional, he gets the assertion. I've updated all call sites to the new API, choosing between the two options according to the function they were calling originally, except that I've updated the usage in DWARFExpression.cpp to use the "safe" method instead, and added a test case which would have previously triggered an assertion failure when processing (incorrect?) dwarf expressions. Reviewers: dsanders, arsenm, JDevlieghere Subscribers: wdng, aprantl, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67154 llvm-svn: 372710
2019-09-24 17:31:02 +08:00
# RUN: llvm-mc %s -filetype obj -triple x86_64-pc-linux --defsym CASE7=0 -o %t7.o
# RUN: llvm-dwarfdump -debug-loc %t7.o 2>&1 | FileCheck %s --check-prefix=UNKNOWN-REG
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
# CHECK: error: unexpected end of data
DWARFDebugLoc(v4): Add an incremental parsing function Summary: This adds a visitLocationList function to the DWARF v4 location lists, similar to what already exists for DWARF v5. It follows the approach outlined in previous patches (D69672), where the parsed form is always stored in the DWARF v5 format, which makes it easier for generic code to be built on top of that. v4 location lists are "upgraded" during parsing, and then this upgrade is undone while dumping. Both "inline" and section-based dumping is rewritten to reuse the existing "generic" location list dumper. This means that the output format is consistent for all location lists (the only thing one needs to implement is the function which prints the "raw" form of a location list), and that debug_loc dumping correctly processes base address selection entries, etc. The previous existing debug_loc functionality (e.g., parseOneLocationList) is rewritten on top of the new API, but it is not removed as there is still code which uses them. This will be done in follow-up patches, after I build the API to access the "interpreted" location lists in a generic way (as that is what those users really want). Reviewers: dblaikie, probinson, JDevlieghere, aprantl, SouraVX Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69847
2019-11-05 21:46:54 +08:00
# UNKNOWN-REG: (0x0000000000000000, 0x0000000000000001): DW_OP_regx 0xdeadbeef
MCRegisterInfo: Merge getLLVMRegNum and getLLVMRegNumFromEH Summary: The functions different in two ways: - getLLVMRegNum could return both "eh" and "other" dwarf register numbers, while getLLVMRegNumFromEH only returned the "eh" number. - getLLVMRegNum asserted if the register was not found, while the second function returned -1. The second distinction was pretty important, but it was very hard to infer that from the function name. Aditionally, for the use case of dumping dwarf expressions, we needed a function which can work with both kinds of number, but does not assert. This patch solves both of these issues by merging the two functions into one, returning an Optional<unsigned> value. While the same thing could be achieved by adding an "IsEH" argument to the (renamed) getLLVMRegNumFromEH function, it seemed better to avoid the confusion of two functions and put the choice of asserting into the hands of the caller -- if he checks the Optional value, he can safely process "untrusted" input, and if he blindly dereferences the Optional, he gets the assertion. I've updated all call sites to the new API, choosing between the two options according to the function they were calling originally, except that I've updated the usage in DWARFExpression.cpp to use the "safe" method instead, and added a test case which would have previously triggered an assertion failure when processing (incorrect?) dwarf expressions. Reviewers: dsanders, arsenm, JDevlieghere Subscribers: wdng, aprantl, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67154 llvm-svn: 372710
2019-09-24 17:31:02 +08:00
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
.section .debug_loc,"",@progbits
.ifdef CASE1
.byte 1 # bogus
.endif
.ifdef CASE2
Fix address sizes in the dwarfdump-debug-loc-error-cases test the test is building a 64-bit executable, so the addresses should be 64-bit too. The test was still passing even with smaller address size, but it was hitting the "unexpected end of data" error sooner than it should. llvm-svn: 370882
2019-09-04 19:47:20 +08:00
.quad 0 # starting offset
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
.endif
.ifdef CASE3
Fix address sizes in the dwarfdump-debug-loc-error-cases test the test is building a 64-bit executable, so the addresses should be 64-bit too. The test was still passing even with smaller address size, but it was hitting the "unexpected end of data" error sooner than it should. llvm-svn: 370882
2019-09-04 19:47:20 +08:00
.quad 0 # starting offset
.quad 1 # ending offset
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
.endif
.ifdef CASE4
Fix address sizes in the dwarfdump-debug-loc-error-cases test the test is building a 64-bit executable, so the addresses should be 64-bit too. The test was still passing even with smaller address size, but it was hitting the "unexpected end of data" error sooner than it should. llvm-svn: 370882
2019-09-04 19:47:20 +08:00
.quad 0 # starting offset
.quad 1 # ending offset
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
.word 0 # Loc expr size
.endif
.ifdef CASE5
Fix address sizes in the dwarfdump-debug-loc-error-cases test the test is building a 64-bit executable, so the addresses should be 64-bit too. The test was still passing even with smaller address size, but it was hitting the "unexpected end of data" error sooner than it should. llvm-svn: 370882
2019-09-04 19:47:20 +08:00
.quad 0 # starting offset
.quad 1 # ending offset
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
.word 0 # Loc expr size
Fix address sizes in the dwarfdump-debug-loc-error-cases test the test is building a 64-bit executable, so the addresses should be 64-bit too. The test was still passing even with smaller address size, but it was hitting the "unexpected end of data" error sooner than it should. llvm-svn: 370882
2019-09-04 19:47:20 +08:00
.quad 0 # starting offset
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
.endif
.ifdef CASE6
Fix address sizes in the dwarfdump-debug-loc-error-cases test the test is building a 64-bit executable, so the addresses should be 64-bit too. The test was still passing even with smaller address size, but it was hitting the "unexpected end of data" error sooner than it should. llvm-svn: 370882
2019-09-04 19:47:20 +08:00
.quad 0 # starting offset
.quad 1 # ending offset
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
.word 0xffff # Loc expr size
.endif
MCRegisterInfo: Merge getLLVMRegNum and getLLVMRegNumFromEH Summary: The functions different in two ways: - getLLVMRegNum could return both "eh" and "other" dwarf register numbers, while getLLVMRegNumFromEH only returned the "eh" number. - getLLVMRegNum asserted if the register was not found, while the second function returned -1. The second distinction was pretty important, but it was very hard to infer that from the function name. Aditionally, for the use case of dumping dwarf expressions, we needed a function which can work with both kinds of number, but does not assert. This patch solves both of these issues by merging the two functions into one, returning an Optional<unsigned> value. While the same thing could be achieved by adding an "IsEH" argument to the (renamed) getLLVMRegNumFromEH function, it seemed better to avoid the confusion of two functions and put the choice of asserting into the hands of the caller -- if he checks the Optional value, he can safely process "untrusted" input, and if he blindly dereferences the Optional, he gets the assertion. I've updated all call sites to the new API, choosing between the two options according to the function they were calling originally, except that I've updated the usage in DWARFExpression.cpp to use the "safe" method instead, and added a test case which would have previously triggered an assertion failure when processing (incorrect?) dwarf expressions. Reviewers: dsanders, arsenm, JDevlieghere Subscribers: wdng, aprantl, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67154 llvm-svn: 372710
2019-09-24 17:31:02 +08:00
.ifdef CASE7
.quad 0 # starting offset
.quad 1 # ending offset
.word 2f-1f # Loc expr size
1:
.byte 0x90 # DW_OP_regx
.uleb128 0xdeadbeef
2:
.quad 0 # starting offset
.quad 0 # ending offset
.endif
DWARFDebugLoc: Make parsing and error reporting more robust Summary: While examining this class for possible use in lldb, I noticed two things: - it spits out parsing errors directly to stderr - the loclists parser can incorrectly return valid location lists when parsing malformed (truncated) data I improve the stderr situation by making the parseOneLocationList functions return Expected<T>s. The errors are still dumped to stderr by their callers, so this is only a partial fix, but it is enough for my use case, as I intend to parse the locations lists one by one. I fix the behavior in the truncated scenario by using the newly introduced DataExtractor Cursor API. I also add tests for handling the error cases, as they currently have no coverage. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63591 llvm-svn: 370363
2019-08-29 22:26:05 +08:00
# A minimal compile unit is needed to deduce the address size of the location
# lists
.section .debug_info,"",@progbits
.long .Lcu_end0-.Lcu_begin0 # Length of Unit
.Lcu_begin0:
.short 4 # DWARF version number
.long 0 # Offset Into Abbrev. Section
.byte 8 # Address Size (in bytes)
.byte 0 # End Of Children Mark
.Lcu_end0: