|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
28c878ae |
| 14-Mar-2022 |
Shafik Yaghmour <[email protected]> |
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB
Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in cl
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB
Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config.
Differential Revision: https://reviews.llvm.org/D121481
show more ...
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
| #
15983c28 |
| 16-Feb-2022 |
Zequan Wu <[email protected]> |
[LLDB] Dump valid ranges of variables
This allows `image lookup -a ... -v` to print variables only if the given address is covered by the valid ranges of the variables. Since variables created in dw
[LLDB] Dump valid ranges of variables
This allows `image lookup -a ... -v` to print variables only if the given address is covered by the valid ranges of the variables. Since variables created in dwarf plugin always has empty scope range, print the variable if it has empty scope.
Differential Revision: https://reviews.llvm.org/D119963
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1 |
|
| #
66902a32 |
| 14-Nov-2019 |
Vedant Kumar <[email protected]> |
[StopInfoMachException] Summarize arm64e BLRAx/LDRAx auth failures
Upstream lldb support for summarizing BLRAx and LDRAx auth failures.
rdar://41615322
Differential Revision: https://reviews.llvm.
[StopInfoMachException] Summarize arm64e BLRAx/LDRAx auth failures
Upstream lldb support for summarizing BLRAx and LDRAx auth failures.
rdar://41615322
Differential Revision: https://reviews.llvm.org/D102428
show more ...
|
| #
76e47d48 |
| 26-May-2021 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivale
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
show more ...
|
| #
1435f6b0 |
| 30-Apr-2021 |
Med Ismail Bennani <[email protected]> |
[lldb] Move and clean-up the Declaration class (NFC)
This patch moves the Declaration class from the Symbol library to the Core library. This will allow to use it in a more generic fashion and aims
[lldb] Move and clean-up the Declaration class (NFC)
This patch moves the Declaration class from the Symbol library to the Core library. This will allow to use it in a more generic fashion and aims to lower the dependency cycles when it comes to the linking.
The patch also does some cleaning up by making column information permanent and removing the LLDB_ENABLE_DECLARATION_COLUMNS directives.
Differential revision: https://reviews.llvm.org/D101556
Signed-off-by: Med Ismail Bennani <[email protected]>
show more ...
|
| #
e9fe788d |
| 16-Apr-2021 |
Jason Molenda <[email protected]> |
Target::ReadMemory read from read-only binary file Section, not memory
Commiting this patch for Augusto Noronha who is getting set up still.
This patch changes Target::ReadMemory so the default beh
Target::ReadMemory read from read-only binary file Section, not memory
Commiting this patch for Augusto Noronha who is getting set up still.
This patch changes Target::ReadMemory so the default behavior when a read is in a Section that is read-only is to fetch the data from the local binary image, instead of reading it from memory. Update all callers to use their old preferences (the old prefer_file_cache bool) using the new API; we should revisit these calls and see if they really intend to read live memory, or if reading from a read-only Section would be equivalent and important for performance-sensitive cases.
rdar://30634422
Differential revision: https://reviews.llvm.org/D100338
show more ...
|
| #
3a168297 |
| 13-May-2020 |
Pavel Labath <[email protected]> |
[lldb] Switch Section-dumping code to raw_ostream
Also, add a basic test for dumping sections.
|
| #
80814287 |
| 24-Jan-2020 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp ----------------------------------------
[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
show more ...
|
| #
1462f5a4 |
| 05-Dec-2019 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Move Address and AddressRange functions out of Stream and let them take raw_ostream
Summary: Yet another step on the long road towards getting rid of lldb's Stream class.
We probably sh
[lldb][NFC] Move Address and AddressRange functions out of Stream and let them take raw_ostream
Summary: Yet another step on the long road towards getting rid of lldb's Stream class.
We probably should just make this some kind of member of Address/AddressRange, but it seems quite often we just push in random integers in there and this is just about getting rid of Stream and not improving arbitrary APIs.
I had to rename another `DumpAddress` function in FormatEntity that is dumping the content of an address to make Clang happy.
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71052
show more ...
|
| #
d1782133 |
| 25-Nov-2019 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Allow range-based for-loops on VariableList
Summary: Adds support for doing range-based for-loops on LLDB's VariableList and modernises all the index-based for-loops in LLDB where possib
[lldb][NFC] Allow range-based for-loops on VariableList
Summary: Adds support for doing range-based for-loops on LLDB's VariableList and modernises all the index-based for-loops in LLDB where possible.
Reviewers: labath, jdoerfert
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70668
show more ...
|
|
Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2 |
|
| #
d5d47a35 |
| 05-Aug-2019 |
Pavel Labath <[email protected]> |
Remove SymbolVendor::GetSymtab
Summary: This patch removes the GetSymtab method from the SymbolVendor, which is a no-op as it's implementation just forwards to the relevant SymbolFile. Instead it cr
Remove SymbolVendor::GetSymtab
Summary: This patch removes the GetSymtab method from the SymbolVendor, which is a no-op as it's implementation just forwards to the relevant SymbolFile. Instead it creates a Module::GetSymtab, which calls the SymbolFile method directly.
All callers have been updated to use the Module method directly instead of a two phase GetSymbolVendor->GetSymtab search, which leads to reduced intentation in a lot of deeply nested code.
Reviewers: clayborg, JDevlieghere, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65569
llvm-svn: 367820
show more ...
|
| #
31e6dbe1 |
| 02-Aug-2019 |
Joseph Tremoulet <[email protected]> |
Fix PC adjustment in StackFrame::GetSymbolContext
Summary: Update StackFrame::GetSymbolContext to mirror the logic in RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the pc decrem
Fix PC adjustment in StackFrame::GetSymbolContext
Summary: Update StackFrame::GetSymbolContext to mirror the logic in RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the pc decrement when the given frame is a signal trap handler frame or the parent of one, because the pc may not follow a call in these frames. Accomplish this by adding a behaves_like_zeroth_frame field to lldb_private::StackFrame, set to true for the zeroth frame, for signal handler frames, and for parents of signal handler frames.
Also add logic to propagate the signal handler flag from UnwindPlan to the FrameType on the RegisterContextLLDB it generates, and factor out a helper to resolve symbol and address range for an Address now that we need to invoke it in four places.
Reviewers: jasonmolenda, clayborg, jfb
Reviewed By: jasonmolenda
Subscribers: labath, dexonsmith, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64993
llvm-svn: 367691
show more ...
|
|
Revision tags: llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2 |
|
| #
09ad8c8f |
| 24-May-2019 |
Jonas Devlieghere <[email protected]> |
Fix integer literals which are cast to bool
This change replaces built-in types that are implicitly converted to booleans.
Differential revision: https://reviews.llvm.org/D62284
llvm-svn: 361580
|
|
Revision tags: llvmorg-8.0.1-rc1 |
|
| #
8b3af63b |
| 10-Apr-2019 |
Jonas Devlieghere <[email protected]> |
[NFC] Remove ASCII lines from comments
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment.
Its use is not really consistent across the code base
[NFC] Remove ASCII lines from comments
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment.
Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment.
I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn.
Differential revision: https://reviews.llvm.org/D60508
llvm-svn: 358135
show more ...
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
| #
8cfb12b9 |
| 30-Nov-2018 |
Aleksandr Urakov <[email protected]> |
[Symbol] Search symbols with name and type in a symbol file
Summary: This patch adds possibility of searching a public symbol with name and type in a symbol file, not only in a symtab. It is helpful
[Symbol] Search symbols with name and type in a symbol file
Summary: This patch adds possibility of searching a public symbol with name and type in a symbol file, not only in a symtab. It is helpful when working with PE, because PE's symtabs contain only imported / exported symbols only. Such a search is required for e.g. evaluation of an expression that calls some function of the debuggee.
Reviewers: zturner, asmith, labath, clayborg, espindola
Reviewed By: clayborg
Subscribers: davide, emaste, arichardson, aleksandr.urakov, jingham, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53368
llvm-svn: 347960
show more ...
|
| #
672d2c12 |
| 11-Nov-2018 |
Jonas Devlieghere <[email protected]> |
Remove comments after header includes.
This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are of
Remove comments after header includes.
This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain.
Differential revision: https://reviews.llvm.org/D54385
llvm-svn: 346625
show more ...
|
|
Revision tags: llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
| #
991e4453 |
| 25-Oct-2018 |
Zachary Turner <[email protected]> |
Don't type-erase the SymbolContextItem enumeration.
When we get the `resolve_scope` parameter from the SB API, it's a `uint32_t`. We then pass it through all of LLDB this way, as a uint32. This is
Don't type-erase the SymbolContextItem enumeration.
When we get the `resolve_scope` parameter from the SB API, it's a `uint32_t`. We then pass it through all of LLDB this way, as a uint32. This is unfortunate, because it means the user of an API never actually knows what they're dealing with. We can call it something like `resolve_scope` and have comments saying "this is a value from the `SymbolContextItem` enumeration, but it makes more sense to just have it actually *be* the correct type in the actual C++ type system to begin with. This way the person reading the code just knows what it is.
The reason to use integers instead of enumerations for flags is because when you do bitwise operations on enumerations they get promoted to integers, so it makes it tedious to constantly be casting them back to the enumeration types, so I've introduced a macro to make this happen magically. By writing LLDB_MARK_AS_BITMASK_ENUM after defining an enumeration, it will define overloaded operators so that the returned type will be the original enum. This should address all the mechanical issues surrounding using rich enum types directly.
This way, we get a better debugger experience, and new users to the codebase can get more easily acquainted with the codebase because their IDE features can help them understand what the types mean.
Differential Revision: https://reviews.llvm.org/D53597
llvm-svn: 345313
show more ...
|
|
Revision tags: llvmorg-7.0.0 |
|
| #
ae3f793e |
| 10-Sep-2018 |
Davide Italiano <[email protected]> |
Rollback "Fix raw address breakpoints not resolving".
It broke a bunch of bots. Ted confirmed, but can't revert for now so I'm reverting on his behalf.
llvm-svn: 341878
|
| #
860bafa0 |
| 10-Sep-2018 |
Ted Woodward <[email protected]> |
Fix raw address breakpoints not resolving
Summary: An address breakpoint of the form "b 0x1000" won't resolve if it's created while the process isn't running. This patch deletes Address::SectionWasD
Fix raw address breakpoints not resolving
Summary: An address breakpoint of the form "b 0x1000" won't resolve if it's created while the process isn't running. This patch deletes Address::SectionWasDeleted, renames Address::SectionWasDeletedPrivate to SectionWasDeleted (and makes it public), and changes the section check in Breakpoint::ModulesChanged back to its original form
Reviewers: jingham, #lldb
Reviewed By: jingham
Subscribers: davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D51816
llvm-svn: 341849
show more ...
|
|
Revision tags: llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1 |
|
| #
04803b3e |
| 26-Jun-2018 |
Tatyana Krasnukha <[email protected]> |
Change AddressClass type from 'enum' to 'enum class'.
If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler.
Change AddressClass type from 'enum' to 'enum class'.
If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa.
llvm-svn: 335599
show more ...
|
|
Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2 |
|
| #
05097246 |
| 30-Apr-2018 |
Adrian Prantl <[email protected]> |
Reflow paragraphs in comments.
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to r
Reflow paragraphs in comments.
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue
if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2)
continue
if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
show more ...
|
|
Revision tags: llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2 |
|
| #
5f19b907 |
| 13-Nov-2017 |
Pavel Labath <[email protected]> |
Move ArchSpec to the Utility module
The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module.
This
Move ArchSpec to the Utility module
The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module.
This commit touches many files, but most of it is just renaming of #include lines. In a couple of cases, I removed the #include ArchSpec line altogether, as the file was not using it. In one or two places, this necessitated adding other #includes like lldb-private-defines.h.
llvm-svn: 318048
show more ...
|
|
Revision tags: llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3 |
|
| #
c3c72122 |
| 08-Jun-2017 |
Pavel Labath <[email protected]> |
Fix backtrace of noreturn functions situated at the end of a module
Summary: When a call instruction is the last instruction in a function, the backtrace PC will point past the end of the function.
Fix backtrace of noreturn functions situated at the end of a module
Summary: When a call instruction is the last instruction in a function, the backtrace PC will point past the end of the function. We already had special code to handle that, but we did not handle the case where the PC ends up outside of the bounds of the module containing the function, which is a situation that occured in TestNoreturnUnwind on android for some arch/compiler combinations.
I fix this by adding an argument to Address resolution code which states that we are ok with addresses pointing to the end of a module/section to resolve to that module/section.
I create a reproducible test case for this situation by hand-crafting an executable which has a noreturn function at the end of a module.
Reviewers: jasonmolenda, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32022
llvm-svn: 304976
show more ...
|
|
Revision tags: llvmorg-4.0.1-rc2 |
|
| #
97206d57 |
| 12-May-2017 |
Zachary Turner <[email protected]> |
Rename Error -> Status.
This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without find and replace, but that h
Rename Error -> Status.
This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious.
llvm-svn: 302872
show more ...
|