Commit Graph

79 Commits

Author SHA1 Message Date
Jason Molenda e9fe788d32 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
2021-04-16 16:13:07 -07:00
Ted Woodward 3169d920cc Remove special Hexagon packet traversal code
On Hexagon, breakpoints need to be on the first instruction of a packet.
When the LLVM disassembler for Hexagon returned 32 bit instructions, we
needed code to find the start of the current packet. Now that the LLVM
disassembler for Hexagon returns packets instead of instructions, we always
have the first instruction of the packet. Remove the packet traversal code
because it can cause problems when the next packet has more than one
instruction.

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D84966
2020-08-05 12:05:42 -05:00
Eric Christopher 3ccd454c10 Fix unused variable, format, and format string warnings.
NFC.
2020-04-03 17:58:59 -07:00
Jim Ingham e4598dc04a Make ThreadPlans use TID and Process, rather than Thread *.
Differential Revision: https://reviews.llvm.org/D75711
2020-04-03 14:56:28 -07:00
Pavel Labath 04592d5b23 [lldb] s/ExecutionContext/Target in Disassembler
Some functions in this file only use the "target" component of an
execution context. Adjust the argument lists to reflect that.

This avoids some defensive null checks and simplifies most of the
callers.
2020-03-05 14:46:39 +01:00
Raphael Isemann 808142876c [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
2020-01-24 08:52:55 +01:00
Pavel Labath 05c3b36bc9 [lldb] Fix a -Wreturn-type warning on gcc 2019-12-20 15:19:41 +01:00
Raphael Isemann 3c6554be2e [lldb] Fix unused variable warning in ThreadPlanStepRange.cpp
This was added in 434905b97d.
Remove it to fix the compiler warnings for this.
2019-12-17 08:53:06 +01:00
Jim Ingham 434905b97d Run all threads when extending a next range over a call.
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
2019-12-16 17:45:21 -08:00
Jonas Devlieghere 63e5fb76ec [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)
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
2019-07-24 17:56:10 +00:00
Greg Clayton df225764b7 Improve step over performance by not stopping at branches that are function 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
2019-05-09 20:39:34 +00:00
Greg Clayton 8a7779209d Include inlined functions when figuring out a contiguous address range
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
2019-05-06 20:01:21 +00:00
Jonas Devlieghere 8b3af63b89 [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
2019-04-10 20:48:55 +00:00
Chandler Carruth 2946cd7010 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
2019-01-19 08:50:56 +00:00
Jonas Devlieghere e103ae92ef Add setting to require hardware breakpoints.
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
2018-11-15 01:18:15 +00:00
Jonas Devlieghere ceff6644bb Remove header grouping comments.
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
2018-11-11 23:17:06 +00:00
Adrian Prantl 05097246f3 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
2018-04-30 16:49:04 +00:00
Zachary Turner 6f9e690199 Move Log from Core -> Utility.
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
2017-03-03 20:56:28 +00:00
Boris Ulasevich 86aaa8a28d Bug 30863 - Step doesn't stop with conditional breakpoint on the next line
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
2017-02-15 11:42:47 +00:00
Zachary Turner bf9a77305f Move classes from Core -> Utility.
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
2017-02-02 21:39:50 +00:00
Boris Ulasevich 67346ca9ef Unroll r292930 due to TestCallThatThrows test fail is not fixed in reasonable time.
llvm-svn: 293269
2017-01-27 07:51:43 +00:00
Boris Ulasevich 29a8eba974 Bug 30863 - Step doesn't stop with conditional breakpoint on the next line
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
2017-01-24 13:15:19 +00:00
Boris Ulasevich 9cc1e19603 Rollback my commit r290168 to fix linux tests failure. I'll be back!
llvm-svn: 290197
2016-12-20 20:00:58 +00:00
Boris Ulasevich 881989cb69 Bug 30863 - Step doesn't stop with coditional breakpoint on the next line
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
2016-12-20 08:09:50 +00:00
Kate Stone b9c1b51e45 *** This commit represents a complete reformatting of the LLDB source code
*** 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
2016-09-06 20:57:50 +00:00
Greg Clayton 32c940de37 Now that there are no cycles that cause leaks in the disassembler/instruction classes, we can get rid of the FIXME lines that were working around this issue.
<rdar://problem/26684190>

llvm-svn: 272071
2016-06-07 23:19:00 +00:00
Ted Woodward 911d57840a Keep original source path and mapped path in LineEntry
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
2016-05-11 22:46:53 +00:00
Eugene Zelenko e65b2cf297 Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in some files in source/Target/.
Simplify smart pointers checks in conditions. Other minor fixes.

llvm-svn: 255598
2015-12-15 01:33:19 +00:00
Jason Molenda 25d5b10b22 When constructing an address range to "step" or "next" through,
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
2015-12-15 00:40:30 +00:00
Jim Ingham a3f466b9e7 Fix commit 252963 to work around a bug on some platforms where they don't
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
2015-11-13 03:37:48 +00:00
Ying Chen 1f6689eae3 Revert "Another little stepping optimization: if any of the source step 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
2015-11-13 00:31:21 +00:00
Jim Ingham 127be38fb8 Another little stepping optimization: if any of the source step commands are 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
2015-11-12 22:32:09 +00:00
Pavel Labath 8c0970febd Fix compiler warning in ThreadPlanStepRange
llvm-svn: 242403
2015-07-16 14:21:49 +00:00
Jason Molenda 25c34d9464 Small fix to ThreadPlanStepRange::DumpRanges to logging
output when stepping through multiple ranges.

llvm-svn: 242243
2015-07-14 23:17:29 +00:00
Greg Clayton 358cf1ea30 Resubmitting 240466 after fixing the linux test suite failures.
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
2015-06-25 21:46:34 +00:00
Ted Woodward e76e7e9369 Add Hexagon packet support to ThreadPlanStepRange
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
2015-05-11 21:12:33 +00:00
Zachary Turner 3294de270e Move lldb-log.cpp to core/Logging.cpp
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
2015-03-18 18:20:42 +00:00
Jim Ingham 2bdbfd50d2 This checkin is the first step in making the lldb thread stepping mechanism 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
2014-09-29 23:17:18 +00:00
Jim Ingham 76447851ad Fetching the parent frame may fail, handle that case. Patch from Tong Shen.
llvm-svn: 215411
2014-08-11 23:57:43 +00:00
Jim Ingham 862d1bbdf6 When stepping, handle the case where the step leaves us with
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
2014-08-06 01:49:59 +00:00
Deepak Panickal 99fbc07600 Fix Windows build using portable types for formatting the log outputs
llvm-svn: 202723
2014-03-03 15:39:47 +00:00
Jason Molenda b57e4a1bc6 Roll back the changes I made in r193907 which created a new Frame
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
2013-11-04 09:33:30 +00:00
Jason Molenda f23bf7432c Add a new base class, Frame. It is a pure virtual function which
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
2013-11-02 02:23:02 +00:00
Greg Clayton eb023e75dc <rdar://problem/13635174>
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
2013-10-11 19:48:25 +00:00
Jim Ingham 2b89a53181 DWARF says line number 0 is a valid line number - used to indicate a source 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
2013-09-27 01:15:46 +00:00
Jason Molenda 6b3e6d5487 Disassembler::DisassembleRange() currently calls Target::ReadMemory
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
2013-09-12 23:23:35 +00:00
Jason Molenda 975abffee7 Re-enable fast stepping for arm targets. The issue being worked
around was fixed in llvm commit r186846.
<rdar://problem/14489274> 

llvm-svn: 187620
2013-08-01 21:50:20 +00:00
Jim Ingham 56d404281f The DisassemblerLLVMC has a retain cycle - the InstructionLLVMC's contained 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
2013-07-31 02:19:15 +00:00
Jim Ingham 63c5c2a0d8 Turn off fast stepping for ARM till the MC's MayAffectControlFlow gets more accurate.
rdar://problem/14488761

llvm-svn: 186646
2013-07-19 02:18:31 +00:00
Greg Clayton 5160ce5c72 <rdar://problem/13521159>
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
2013-03-27 23:08:40 +00:00