summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/ThreadPlanStepRange.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Fix a -Wreturn-type warning on gccPavel Labath2019-12-201-0/+1
|
* [lldb] Fix unused variable warning in ThreadPlanStepRange.cppRaphael Isemann2019-12-171-1/+0
| | | | | This was added in 434905b97d961531286d4b49c7ee1969f7cbea0e. Remove it to fix the compiler warnings for this.
* Run all threads when extending a next range over a call.Jim Ingham2019-12-161-3/+19
| | | | | | | | | If you don't do this you end up running arbitrary code with only one thread allowed to run, which can cause deadlocks. <rdar://problem/56422478> Differential Revision: https://reviews.llvm.org/D71440
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-241-28/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
* Improve step over performance by not stopping at branches that are function ↵Greg Clayton2019-05-091-3/+4
| | | | | | | | | | calls and stepping into and them out of each one Currently when we single step over a source line, we run and stop at every branch in the source line range. We can reduce the number of times we stop when stepping over by figuring out if any of these branches are function calls, and if so, ignore these branches. Since we are stepping over we can safely ignore these calls since they will return to the next instruction. Currently the step logic would stop at those branches (1st stop), single step into the branch (2nd stop), and then set a breakpoint at the return address (3rd stop), and then continue. Differential Revision: https://reviews.llvm.org/D58678 llvm-svn: 360375
* Include inlined functions when figuring out a contiguous address rangeGreg Clayton2019-05-061-4/+8
| | | | | | | | | | | | | | | | | | | | | | | Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-2/+0
| | | | | | | | | | | | | | | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* Add setting to require hardware breakpoints.Jonas Devlieghere2018-11-151-1/+17
| | | | | | | | | | | | | | | | When debugging read-only memory we cannot use software breakpoint. We already have support for hardware breakpoints and users can specify them with `-H`. However, there's no option to force LLDB to use hardware breakpoints internally, for example while stepping. This patch adds a setting target.require-hardware-breakpoint that forces LLDB to always use hardware breakpoints. Because hardware breakpoints are a limited resource and can fail to resolve, this patch also extends error handling in thread plans, where breakpoints are used for stepping. Differential revision: https://reviews.llvm.org/D54221 llvm-svn: 346920
* Remove header grouping comments.Jonas Devlieghere2018-11-111-4/+0
| | | | | | | | This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-26/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Bug 30863 - Step doesn't stop with conditional breakpoint on the next lineBoris Ulasevich2017-02-151-0/+10
| | | | | | | | | Differential Revisions: https://reviews.llvm.org/D26497 (committed r290168, temporary reverted r290197) https://reviews.llvm.org/D28945 (fix for Ubuntu tests fail) https://reviews.llvm.org/D29909 (fix for TestCallThatThrows test fail) llvm-svn: 295168
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Unroll r292930 due to TestCallThatThrows test fail is not fixed in ↵Boris Ulasevich2017-01-271-10/+0
| | | | | | reasonable time. llvm-svn: 293269
* Bug 30863 - Step doesn't stop with conditional breakpoint on the next lineBoris Ulasevich2017-01-241-0/+10
| | | | | | | | Differential Revisions: https://reviews.llvm.org/D26497 (committed r290168, temporary reverted r290197) https://reviews.llvm.org/D28945 (fix for Ubuntu tests fail) llvm-svn: 292930
* Rollback my commit r290168 to fix linux tests failure. I'll be back!Boris Ulasevich2016-12-201-10/+0
| | | | llvm-svn: 290197
* Bug 30863 - Step doesn't stop with coditional breakpoint on the next lineBoris Ulasevich2016-12-201-0/+10
| | | | | | | | | Fixed by additional completed plans detection, and applying them on breakpoint condition fail. Thread::GetStopInfo reworked. New test added. Review https://reviews.llvm.org/D26497 Many thanks to Jim llvm-svn: 290168
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-444/+374
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Now that there are no cycles that cause leaks in the ↵Greg Clayton2016-06-071-10/+0
| | | | | | | | disassembler/instruction classes, we can get rid of the FIXME lines that were working around this issue. <rdar://problem/26684190> llvm-svn: 272071
* Keep original source path and mapped path in LineEntryTed Woodward2016-05-111-1/+1
| | | | | | | | | | | | | | | | | Summary: The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped. Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct. Tests run on Ubuntu 12.04 show no regression. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20135 llvm-svn: 269250
* Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr ↵Eugene Zelenko2015-12-151-31/+12
| | | | | | | | warnings in some files in source/Target/. Simplify smart pointers checks in conditions. Other minor fixes. llvm-svn: 255598
* When constructing an address range to "step" or "next" through,Jason Molenda2015-12-151-2/+2
| | | | | | | | | | | | | | find the largest address range (possibly combining multiple LineEntry's for this line number) that is contiguous. This allows lldb's fast-step stepping algorithm to potentially run for a longer address range than if we have to stop at every LineEntry indicating a subexpression in the source line. http://reviews.llvm.org/D15407 <rdar://problem/23270882> llvm-svn: 255590
* Fix commit 252963 to work around a bug on some platforms where they don't Jim Ingham2015-11-131-3/+13
| | | | | | | | correctly handle stepping over one breakpoint directly onto another breakpoint. This isn't fixing that bug, but rather just changing 252963 to not use breakpoints if it is only stepping one instruction. llvm-svn: 253008
* Revert "Another little stepping optimization: if any of the source step ↵Ying Chen2015-11-131-9/+2
| | | | | | | | | | commands are running through a range " - Revert because this commit introduce several failures in lldb test suite - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391 - This reverts commit 78943bb678c2893703ee4e8b41969372740c8a6f. llvm-svn: 252980
* Another little stepping optimization: if any of the source step commands are ↵Jim Ingham2015-11-121-2/+9
| | | | | | | | | | | | | | | | | | | | | running through a range of addresses, and the range has no branches, instead of running to the last instruction and single-stepping over that, run to the first instruction after the end of the range. If there are no branches in the current range, then the bytes right after it have to be in the current function, and have to be instructions not data in code, so this is safe. And it cuts down one extra stepi per source range step. Incidentally, this also works around a bug in the llvm Intel assembler where it treats the "rep" prefix as a separate instruction from the repeated instruction. If that were at the end of a line range, then we would put a trap in place of the repeated instruction, which is undefined behavior. Current processors just ignore the repetition in this case, which changes program behavior. Since there would never be a line range break after the rep prefix, always doing the range stepping to the beginning of the new range avoids this problem. <rdar://problem/23461686> llvm-svn: 252963
* Fix compiler warning in ThreadPlanStepRangePavel Labath2015-07-161-1/+1
| | | | llvm-svn: 242403
* Small fix to ThreadPlanStepRange::DumpRanges to loggingJason Molenda2015-07-141-1/+1
| | | | | | output when stepping through multiple ranges. llvm-svn: 242243
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-251-2/+2
| | | | | | | | | | | | | | | A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
* Add Hexagon packet support to ThreadPlanStepRangeTed Woodward2015-05-111-1/+2
| | | | | | | | | | | | | | | | | Summary: Hexagon is a VLIW processor. It can execute multiple instructions at once, called a packet. Breakpoints need to be alone in a packet. This patch will make sure that temporary breakpoints used for stepping are set at the start of a packet, which will put the breakpoint in a packet by itself. Patch by Deepak Panickal of CodePlay and Ted Woodward of Qualcomm. Reviewers: deepak2427, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9437 llvm-svn: 237047
* Move lldb-log.cpp to core/Logging.cppZachary Turner2015-03-181-2/+0
| | | | | | | | | So that we don't have to update every single #include in the entire codebase to #include this new header (which used to get included by lldb-private-log.h, we automatically #include "Logging.h" from within "Log.h". llvm-svn: 232653
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-291-3/+5
| | | | | | | | | | | | more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
* Fetching the parent frame may fail, handle that case. Patch from Tong Shen.Jim Ingham2014-08-111-2/+7
| | | | llvm-svn: 215411
* When stepping, handle the case where the step leaves us withJim Ingham2014-08-061-1/+9
| | | | | | | | | | the same parent frame, but different current frame - e.g. when you step past a tail call exit from a function. Apply the same "avoid-no-debug" rules to this case as for a "step-in". <rdar://problem/16189225> llvm-svn: 214946
* Fix Windows build using portable types for formatting the log outputsDeepak Panickal2014-03-031-2/+2
| | | | llvm-svn: 202723
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-1/+1
| | | | | | | | | | pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-1/+1
| | | | | | | | | | | | | | | | | | | | | defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
* <rdar://problem/13635174>Greg Clayton2013-10-111-1/+1
| | | | | | | | Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging. Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function. llvm-svn: 192491
* DWARF says line number 0 is a valid line number - used to indicate a source ↵Jim Ingham2013-09-271-0/+19
| | | | | | | | | | line that should not have breakpoints set on it inserted into code that does have a valid line number. So allow that line number, and the ThreadPlanStepRange should just continue stepping over 0 line ranges as if they had the same line number as whatever we were previously stepping through. llvm-svn: 191477
* Disassembler::DisassembleRange() currently calls Target::ReadMemoryJason Molenda2013-09-121-1/+3
| | | | | | | | | | | | | with prefer_file_cache == false. This is what we want to do when the user is doing a disassemble command -- show the actual memory contents in case the memory has been corrupted or something -- but when we're profiling functions for stepping or unwinding (ThreadPlanStepRange::GetInstructionsForAddress, UnwindAssemblyInstEmulation::GetNonCallSiteUnwindP) we can read __TEXT instructions directly out of the file, if it exists. <rdar://problem/14397491> llvm-svn: 190638
* Re-enable fast stepping for arm targets. The issue being workedJason Molenda2013-08-011-5/+1
| | | | | | | around was fixed in llvm commit r186846. <rdar://problem/14489274> llvm-svn: 187620
* The DisassemblerLLVMC has a retain cycle - the InstructionLLVMC's contained ↵Jim Ingham2013-07-311-0/+13
| | | | | | | | | | | | in its instruction list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this for real when I have time to do so. <rdar://problem/14581918> llvm-svn: 187473
* Turn off fast stepping for ARM till the MC's MayAffectControlFlow gets more ↵Jim Ingham2013-07-191-1/+5
| | | | | | | | accurate. rdar://problem/14488761 llvm-svn: 186646
* <rdar://problem/13521159>Greg Clayton2013-03-271-7/+7
| | | | | | | | LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
* Add a target setting (target.use-fast-stepping) to control using the "run to ↵Jim Ingham2013-03-131-0/+1
| | | | | | next branch" stepping algorithm. llvm-svn: 176958
* The step by running from branch to branch pretty much works with this ↵Jim Ingham2013-03-131-7/+61
| | | | | | | | | checkin (at least for x86_64) but is still turned off, it needs more qualification. If you want to play with it, change the initialization of m_use_fast_step to true. llvm-svn: 176923
* Convert from the C-based LLVM Disassembler shim to the full MC Disassembler ↵Jim Ingham2013-03-021-1/+4
| | | | | | | | | | | | API's. Calculate "can branch" using the MC API's rather than our hand-rolled regex'es. As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att. <rdar://problem/11319574> <rdar://problem/9329275> llvm-svn: 176392
* Add "target.process.stop-on-shared-library-events" setting, and make it work.Jim Ingham2013-01-261-2/+7
| | | | | | | | | | | Add the ability to give breakpoints a "kind" string, and have the StopInfoBreakpoint print that in the brief description if set. Also print the kind - if set - in the breakpoint listing. Give kinds to a bunch of the internal breakpoints. We were deleting the Mac OS X dynamic loader breakpoint as though the id we had stored away was a breakpoint site ID, but in fact it was a breakpoint id, so we never actually deleted it. Fixed that. llvm-svn: 173555
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-1/+1
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* Shortcut ThreadPlanStepRange::MischiefManaged - if we have pushed new plans ↵Jim Ingham2012-09-101-6/+20
| | | | | | | | and they are not done, then we aren't done either. <rdar://problem/12259124> llvm-svn: 163572
OpenPOWER on IntegriCloud