Commit Graph

31 Commits

Author SHA1 Message Date
Jonas Devlieghere a8f3ae7c9c [LLDB] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

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

llvm-svn: 368933
2019-08-14 22:19:23 +00:00
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 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 581af8b09d [SBAPI] Log from record macro
The current record macros already log the function being called. This
patch extends the macros to also log their input arguments and removes
explicit logging from the SB API.

This might degrade the amount of information in some cases (because of
smarter casts or efforts to log return values). However I think this is
outweighed by the increased coverage and consistency. Furthermore, using
the reproducer infrastructure, diagnosing bugs in the API layer should
become much easier compared to relying on log messages.

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

llvm-svn: 355649
2019-03-07 22:47:13 +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 bd4bf82a48 [SBAPI] Don't check IsValid in constructor
When running the test suite with the instrumentation macros, I noticed
two lldb-mi tests regressed. The issue was the copy constructor of
SBLineEntry. Without the macros the returned value would be elided, but
with the macros the copy constructor was called. The latter using ::IsValid
to determine whether the underlying opaque pointer should be set. This
is likely a remnant of when ::IsValid would only check the validity of the
smart pointer. In SBLineEntry however, it actually forwards to
LineEntry::IsValid().

So what happened here was that because of the macros the copy
constructor was called. The opaque pointer was valid but the LineEntry
didn't consider itself valid. So the copied-to object ended up default
initialized.

This patch replaces all checks for IsValid in copy (assignment)
constructors with checks for the opaque pointer itself.

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

llvm-svn: 355458
2019-03-06 00:05:55 +00:00
Jonas Devlieghere d5b440369d Replace 'ap' with 'up' suffix in variable names. (NFC)
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.

In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.

I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.

llvm-svn: 353912
2019-02-13 06:25:41 +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 3447077a28 [API] Remove redundants get() from smart pointers. NFC
Removes redundant calls to ::get() from smart pointers in the source/API
directory..

llvm-svn: 349821
2018-12-20 21:02:55 +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
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
Saleem Abdulrasool 324a103619 sweep up -Wformat warnings from gcc
This is a purely mechanical change explicitly casting any parameters for printf
style conversion.  This cleans up the warnings emitted by gcc 4.8 on Linux.

llvm-svn: 205607
2014-04-04 04:06:10 +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
Greg Clayton 72310355ff <rdar://problem/13265297>
StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.

llvm-svn: 175953
2013-02-23 04:12:47 +00:00
Greg Clayton 5569e64ea7 Removed all of the "#ifndef SWIG" from the SB header files since we are using
interface (.i) files for each class.

Changed the FindFunction class from:

uint32_t
SBTarget::FindFunctions (const char *name, 
                         uint32_t name_type_mask, 
                         bool append, 
                         lldb::SBSymbolContextList& sc_list)

uint32_t
SBModule::FindFunctions (const char *name, 
                         uint32_t name_type_mask, 
                         bool append, 
                         lldb::SBSymbolContextList& sc_list)

To:

lldb::SBSymbolContextList
SBTarget::FindFunctions (const char *name, 
                         uint32_t name_type_mask = lldb::eFunctionNameTypeAny);

lldb::SBSymbolContextList
SBModule::FindFunctions (const char *name,
                         uint32_t name_type_mask = lldb::eFunctionNameTypeAny);

This makes the API easier to use from python. Also added the ability to
append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList.

Exposed properties for lldb.SBSymbolContextList in python:

lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list
lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list
lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list
lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list
lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list
lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list

This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...)
and then the result can be used to extract the desired information:

sc_list = lldb.target.FindFunctions("erase")

for function in sc_list.functions:
    print function
for symbol in sc_list.symbols:
    print symbol

Exposed properties for the lldb.SBSymbolContext objects in python:

lldb.SBSymbolContext.module => lldb.SBModule
lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit
lldb.SBSymbolContext.function => lldb.SBFunction
lldb.SBSymbolContext.block => lldb.SBBlock
lldb.SBSymbolContext.line_entry => lldb.SBLineEntry
lldb.SBSymbolContext.symbol => lldb.SBSymbol


Exposed properties for the lldb.SBBlock objects in python:

lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains
lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block
lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block
lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column
lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents
lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block)
lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned
lldb.SBBlock.ranges => an array or all address ranges for this block
lldb.SBBlock.num_ranges => the number of address ranges for this blcok

SBFunction objects can now get the SBType and the SBBlock that represents the
top scope of the function.

SBBlock objects can now get the variable list from the current block. The value
list returned allows varaibles to be viewed prior with no process if code
wants to check the variables in a function. There are two ways to get a variable
list from a SBBlock:

lldb::SBValueList
SBBlock::GetVariables (lldb::SBFrame& frame,
                       bool arguments,
                       bool locals,
                       bool statics,
                       lldb::DynamicValueType use_dynamic);

lldb::SBValueList
SBBlock::GetVariables (lldb::SBTarget& target,
                       bool arguments,
                       bool locals,
                       bool statics);

When a SBFrame is used, the values returned will be locked down to the frame
and the values will be evaluated in the context of that frame.

When a SBTarget is used, global an static variables can be viewed without a
running process.

llvm-svn: 149853
2012-02-06 01:44:54 +00:00
Greg Clayton acdbe81637 lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still
contain shared pointers to the lldb_private::Target and lldb_private::Process
objects respectively as we won't want the target or process just going away.

Also cleaned up the lldb::SBModule to remove dangerous pointer accessors.

For any code the public API files, we should always be grabbing shared 
pointers to any objects for the current class, and any other classes prior
to running code with them.

llvm-svn: 149238
2012-01-30 09:04:36 +00:00
Greg Clayton da7bc7d000 <rdar://problem/10126482>
Fixed an issues with the SBType and SBTypeMember classes:
- Fixed SBType to be able to dump itself from python
- Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces
- Fixed SBTypeMember to be able to dump itself from python
- Fixed the SBTypeMember ability to get a field offset in bytes (the value
  being returned was wrong)
- Added the SBTypeMember ability to get a field offset in bits


Cleaned up a lot of the Stream usage in the SB API files.

llvm-svn: 144493
2011-11-13 06:57:31 +00:00
Greg Clayton 1ed54f50c5 Cleaned up the the code that figures out the inlined stack frames given a
symbol context that represents an inlined function. This function has been
renamed internally to:

bool
SymbolContext::GetParentOfInlinedScope (const Address &curr_frame_pc, 
                                        SymbolContext &next_frame_sc, 
                                        Address &next_frame_pc) const;
                                        
And externally to:

SBSymbolContext
SBSymbolContext::GetParentOfInlinedScope (const SBAddress &curr_frame_pc, 
                                          SBAddress &parent_frame_addr) const;

The correct blocks are now correctly calculated.

Switched the stack backtracing engine (in StackFrameList) and the address
context printing over to using the internal SymbolContext::GetParentOfInlinedScope(...) 
so all inlined callstacks will match exactly.

llvm-svn: 140910
2011-10-01 00:45:15 +00:00
Greg Clayton 8f7180b11e Added more functionality to the public API to allow for better
symbolication. Also improved the SBInstruction API to allow
access to the instruction opcode name, mnemonics, comment and
instruction data.

Added the ability to edit SBLineEntry objects (change the file,
line and column), and also allow SBSymbolContext objects to be
modified (set module, comp unit, function, block, line entry
or symbol). 

The SymbolContext and SBSymbolContext can now generate inlined
call stack infomration for symbolication much easier using the
SymbolContext::GetParentInlinedFrameInfo(...) and 
SBSymbolContext::GetParentInlinedFrameInfo(...) methods.

llvm-svn: 140518
2011-09-26 07:11:27 +00:00
Greg Clayton 2d4edfbc6a Modified all logging calls to hand out shared pointers to make sure we
don't crash if we disable logging when some code already has a copy of the
logger. Prior to this fix, logs were handed out as pointers and if they were
held onto while a log got disabled, then it could cause a crash. Now all logs
are handed out as shared pointers so this problem shouldn't happen anymore.
We are also using our new shared pointers that put the shared pointer count
and the object into the same allocation for a tad better performance.

llvm-svn: 118319
2010-11-06 01:53:30 +00:00
Greg Clayton cfd1aced7e Cleaned up the API logging a lot more to reduce redundant information and
keep the file size a bit smaller.

Exposed SBValue::GetExpressionPath() so SBValue users can get an expression
path for their values.

llvm-svn: 117851
2010-10-31 03:01:06 +00:00
Greg Clayton 4838131baf Improved API logging.
llvm-svn: 117772
2010-10-30 04:51:46 +00:00
Caroline Tice 750cd1755d Clean up the API logging code:
- Try to reduce logging to one line per function call instead of tw
      - Put all arguments & their values into log for calls
      - Add 'this' parameter information to function call logging, making it show the appropriate
        internal pointer (this.obj, this.sp, this.ap...)
      - Clean up some return values
      - Remove logging of constructors that construct empty objects
      - Change '==>' to '=>'  for showing result values...
      - Fix various minor bugs
      - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments...      

llvm-svn: 117417
2010-10-26 23:49:36 +00:00
Caroline Tice ceb6b1393d First pass at adding logging capabilities for the API functions. At the moment
it logs the function calls, their arguments and the return values.  This is not
complete or polished, but I am committing it now, at the request of someone who
really wants to use it, even though it's not really done.  It currently does not
attempt to log all the functions, just the most important ones.  I will be 
making further adjustments to the API logging code over the next few days/weeks.
(Suggestions for improvements are welcome).


Update the Python build scripts to re-build the swig C++ file whenever 
the python-extensions.swig file is modified.

Correct the help for 'log enable' command (give it the correct number & type of
arguments).

llvm-svn: 117349
2010-10-26 03:11:13 +00:00
Caroline Tice dac97f31a3 Remove all the __repr__ methods from the API/*.h files, and put them
into python-extensions.swig, which gets included into lldb.swig, and
adds them back into the classes when swig generates it's C++ file.  This
keeps the Python stuff out of the general API classes.

Also fixed a small bug in the copy constructor for SBSymbolContext.

llvm-svn: 114602
2010-09-22 23:01:29 +00:00
Caroline Tice dde9cff32a Add GetDescription() and __repr__ () methods to most API classes, to allow
"print" from inside Python to print out the objects in a more useful
manner.

llvm-svn: 114321
2010-09-20 05:20:02 +00:00
Greg Clayton 0996003126 Added some missing API for address resolving within a module, and looking
up a seciton offset address (SBAddress) within a module that returns a
symbol context (SBSymbolContext). Also added a SBSymbolContextList in 
preparation for adding find/lookup APIs that can return multiple results.

Added a lookup example code that shows how to do address lookups.

llvm-svn: 113599
2010-09-10 18:31:35 +00:00
Greg Clayton 6611103cfe Very large changes that were needed in order to allow multiple connections
to the debugger from GUI windows. Previously there was one global debugger
instance that could be accessed that had its own command interpreter and
current state (current target/process/thread/frame). When a GUI debugger
was attached, if it opened more than one window that each had a console
window, there were issues where the last one to setup the global debugger
object won and got control of the debugger.

To avoid this we now create instances of the lldb_private::Debugger that each 
has its own state:
- target list for targets the debugger instance owns
- current process/thread/frame
- its own command interpreter
- its own input, output and error file handles to avoid conflicts
- its own input reader stack

So now clients should call:

    SBDebugger::Initialize(); // (static function)

    SBDebugger debugger (SBDebugger::Create());
    // Use which ever file handles you wish
    debugger.SetErrorFileHandle (stderr, false);
    debugger.SetOutputFileHandle (stdout, false);
    debugger.SetInputFileHandle (stdin, true);

    // main loop
    
    SBDebugger::Terminate(); // (static function)
    
SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to
ensure nothing gets destroyed too early when multiple clients might be
attached.

Cleaned up the command interpreter and the CommandObject and all subclasses
to take more appropriate arguments.

llvm-svn: 106615
2010-06-23 01:19:29 +00:00
Chris Lattner 30fdc8d841 Initial checkin of lldb code from internal Apple repo.
llvm-svn: 105619
2010-06-08 16:52:24 +00:00