Commit Graph

47 Commits

Author SHA1 Message Date
Konrad Kleine 248a13057a [lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]

This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.

This is the command I ran and I to fix and format the code base:

```
run-clang-tidy.py \
	-header-filter='.*' \
	-checks='-*,modernize-use-nullptr' \
	-fix ~/dev/llvm-project/lldb/.* \
	-format \
	-style LLVM \
	-p ~/llvm-builds/debug-ninja-gcc
```

NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.

NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.

Reviewers: martong, espindola, shafik, #lldb, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits

Tags: #lldb, #llvm

Differential Revision: https://reviews.llvm.org/D61847

llvm-svn: 361484
2019-05-23 11:14:47 +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
Jonas Devlieghere 306809f292 [Reproducers] Capture return values of functions returning by ptr/ref
For some reason I had convinced myself that functions returning by
pointer or reference do not require recording their result. However,
after further considering I don't see how that could work, at least not
with the current implementation. Interestingly enough, the reproducer
instrumentation already (mostly) accounts for this, though the
lldb-instr tool did not.

This patch adds the missing macros and updates the lldb-instr tool.

Differential revision: https://reviews.llvm.org/D60178

llvm-svn: 357639
2019-04-03 21:31:22 +00:00
Michal Gorny ae211ece6a [lldb] [Reproducer] Move SBRegistry registration into declaring files
Move SBRegistry method registrations from SBReproducer.cpp into files
declaring the individual APIs, in order to reduce the memory consumption
during build and improve maintainability.  The current humongous
SBRegistry constructor exhausts all memory on a NetBSD system with 4G
RAM + 4G swap, therefore making it impossible to build LLDB.

Differential Revision: https://reviews.llvm.org/D59427

llvm-svn: 356481
2019-03-19 17:13:13 +00:00
Pavel Labath 7f5237bccc Add "operator bool" to SB APIs
Summary:
Our python version of the SB API has (the python equivalent of)
operator bool, but the C++ version doesn't.

This is because our python operators are added by modify-python-lldb.py,
which performs postprocessing on the swig-generated interface files.

In this patch, I add the "operator bool" to all SB classes which have an
IsValid method (which is the same logic used by modify-python-lldb.py).
This way, we make the two interfaces more constent, and it allows us to
rely on swig's automatic syntesis of python __nonzero__ methods instead
of doing manual fixups.

Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille

Subscribers: jdoerfert, lldb-commits

Differential Revision: https://reviews.llvm.org/D58792

llvm-svn: 355824
2019-03-11 13:58:46 +00:00
Jonas Devlieghere baf5664f50 [Reproducers] Add SBReproducer macros
This patch adds the SBReproducer macros needed to capture and reply the
corresponding calls. This patch was generated by running the lldb-instr
tool on the API source files.

Differential revision: https://reviews.llvm.org/D57475

llvm-svn: 355459
2019-03-06 00:06:00 +00:00
Jonas Devlieghere 796ac80b86 Use std::make_shared in LLDB (NFC)
Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.

Differential revision: https://reviews.llvm.org/D57990

llvm-svn: 353764
2019-02-11 23:13:08 +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
Tatyana Krasnukha 9e1a117d4b Move AddressClass to private enums since API doesn't provide any functions to manage it.
This change allows to make AddressClass strongly typed enum and not to have issues with old versions of SWIG that don't support enum classes.

llvm-svn: 335710
2018-06-27 06:50:10 +00:00
Tatyana Krasnukha 04803b3ef2 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
2018-06-26 13:06:54 +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
Pavel Labath 5f19b90783 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
2017-11-13 16:16:33 +00:00
Pavel Labath 7263f1bda6 Invert ArchSpec<->Platform dependency
Summary:
ArchSpec::SetTriple was taking a Platform as an argument, and used it to
fill in missing pieces of the specified triple. I invert the dependency
by moving this code to other classes. For this purpose, I've created
three new functions.
- HostInfo::GetAugmentedArchSpec: fills in the triple using the host
  platform (this used to be implemented by passing a null platform
  pointer). By putting this code in the Host module, we can provide a
  way to anyone who does not have a platform instance (lldb-server) an
  easy way to get Host data.
- Platform::GetAugmentedArchSpec: if you have a platform instance, you
  can call this to let it fill in the triple.
- static Platform::GetAugmentedArchSpec: implements the "if platform ==
  0 then use_host() else use_platform()" part.

Reviewers: zturner, jingham, clayborg

Subscribers: mgorny, javed.absar, lldb-commits

Differential Revision: https://reviews.llvm.org/D39387

llvm-svn: 316987
2017-10-31 10:56:03 +00:00
Nitesh Jain dd12594345 [LLDB][MIPS] Fix TestStepOverBreakpoint.py failure.
Reviewers: jingham, labath

Subscribers: jaydeep, bhushan, lldb-commits, slthakur

Differential Revision: https://reviews.llvm.org/D32168

llvm-svn: 302139
2017-05-04 11:34:42 +00:00
Zachary Turner 666cc0b291 Move DataBuffer / DataExtractor and friends from Core -> Utility.
llvm-svn: 296943
2017-03-04 01:30:05 +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 4a9d83a55e Fix a memory leak in InstructionLLVMC where it held onto a strong reference to the DisassemblerLLVMC which in turn had a vector of InstructionSP causing the strong cycle. This is fixed now.
Rules are as follows for internal code using lldb::DisassemblerSP and lldb::InstructionSP:
1 - The disassembler needs to stay around as long as instructions do as the Instruction subclass now has a weak pointer to the disassembler
2 - The public API has been fixed so that if you get a SBInstruction, it will hold onto a strong reference to the disassembler in a new InstructionImpl class

This will keep code like like: 

inst = lldb.target.ReadInstructions(frame.GetPCAddress(), 1).GetInstructionAtIndex(0)
inst.GetMnemonic()

Working as expected (not the SBInstructionList() that was returned by SBTarget.ReadInstructions() is gone, but "inst" has a strong reference inside of it to the disassembler and the instruction.
                                                     
All code inside the LLDB shared library was verified to correctly hold onto the disassembler instance in all places.

<rdar://problem/24585496>

llvm-svn: 272069
2016-06-07 22:56:40 +00:00
Saleem Abdulrasool bb19a13c0b second pass over removal of Mutex and Condition
llvm-svn: 270024
2016-05-19 05:13:57 +00:00
Bhushan D. Attarde df5f0b448c [LLDB][MIPS] A small fix in GetBreakableLoadAddress() for MIPS
SUMMARY:
    Get the load address for the address given by symbol and function.
    Earlier, this was done for function only, this patch does it for symbol too.
    This patch also adds TestAvoidBreakpointInDelaySlot.py to test this change.
    
    Reviewers: clayborg
    Subscribers: labath, zturner, mohit.bhakkad, sagar, jaydeep, lldb-commits
    Differential Revision: http://reviews.llvm.org/D16049

llvm-svn: 258919
2016-01-27 10:16:30 +00:00
Jason Molenda c980fa92eb Change the default disassembly format again. First attempt at
changing it was in r219544 - after living on that for a few 
months, I wanted to take another crack at this.

The disassembly-format setting still exists and the old format
can be user specified with a setting like

${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}: 

This patch was discussed in http://reviews.llvm.org/D7578

<rdar://problem/19726421>

llvm-svn: 229186
2015-02-13 23:24:21 +00:00
Greg Clayton 554f68d385 Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity class.
Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing. 

The new code improves on this with the following features:
1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry.
2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format
3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it.
4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly
5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings
6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features.
7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries.

These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more).

llvm-svn: 228207
2015-02-04 22:00:53 +00:00
Jason Molenda aff1b357b0 Add a new disassembly-format specification so that the disassembler
output style can be customized.  Change the built-in default to be
more similar to gdb's disassembly formatting.

The disassembly-format for a gdb-like output is

${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>: 

The disassembly-format for the lldb style output is

{${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}: 

The two backticks in the lldb style formatter triggers the sub-expression evaluation in
CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to
use ' characters instead of ` would work around that.

<rdar://problem/9885398> 

llvm-svn: 219544
2014-10-10 23:07:36 +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 1f7460716b <rdar://problem/11757916>
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". 
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.

llvm-svn: 162860
2012-08-29 21:13:06 +00:00