Summary:
After r236447, ValueObject::GetAddressOf returns LLDB_INVALID_ADDRESS
when the value type is eValueHostAddress. For such a case, clients of
GetAddressOf should get the address from the scalar part of the value
instead of using the value returned by GetAddressOf directly.
This change also makes ValueObject::GetAddressOf set the address type to
eAddressTypeHost for values of eValueHostAddress so that clients can
recognize that they need to fetch the address from the scalar part
of the value.
Test Plan: ninja check-lldb on linux
Reviewers: clayborg, ovyalov
Reviewed By: ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9490
llvm-svn: 236473
Summary:
This fixes TestRegisterVariables for clang and hence it is enabled in this commit.
Test Plan: dotest.py -C clang -p TestRegisterVariables
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9421
llvm-svn: 236447
an argument pointing into the middle of m_buffer and then
Write() calls GrowBuffer() to resize m_buffer, leaving
the content argument pointing into deallocated memory.
Patch by Kate Stone.
<rdar://problem/20756722>
llvm-svn: 236286
Based on list discussions, a different approach is desired for
reducing the visual impact of logging statements on the
readability of the code. Another mechanism will be added in
a followup patch, but for now, since NullLog is unreferenced,
this patch just removes it.
This patch does *not* remove the other half of r236174, which was
to delete some dead code surrounding logging flags.
llvm-svn: 236259
The purpose of this class is so that GetLogIfAllCategoriesSet
can always return an instance of some class, whether it be a real
logging class or a "null" class, which ignores messages. Code
that is littered with if statements that only log if the pointer
is non-null can get very unwieldy very quickly, so this should
help code readability in such circumstances.
Since I'm in this code anyway, I'm also deleting the
PrintfWithFlags methods, as well as all the flags, since they
appear to be dead code that have been superceded by newer
mechanisms and all the flags are simply ignored.
llvm-svn: 236174
Patch by Jaydeep Patil
Added MIPS32 and MIPS64 core revisions. This would be followed by register context and emulate-instruction for MIPS32.
DYLDRendezvous.cpp:
On Linux link map struct does not contain extra load offset field.
Reviewers: clayborg
Subscribers: bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D9190
llvm-svn: 235574
Previously the read thread was only stopped if CloseOnEOF was set on the
communication channel. It caused it to spin in case of an EOF because
::select() always reported that we can read from the file descriptor.
This CL change this behavior with stopping the read thread on EOF but do
a disconnect only if CloseOnEOF is enabled.
Differential revision: http://reviews.llvm.org/D9077
llvm-svn: 235291
the changes in r233255/r233258. Normally if lldb attaches to
a running process, when we call Process::Destroy, we want to detach
from the process. If lldb launched the process itself, ::Destroy
should kill it.
However, if we attach to a process and the driver calls SBProcess::Kill()
(which calls Destroy), we need to kill it even if we didn't launch it
originally.
The force_kill param allows for the SBProcess::Kill method to force the
behavior of Destroy.
<rdar://problem/20424439>
llvm-svn: 235158
Also fixed an issue with the GUI mode where tree items wouldn't be notified that they were selected. Now selecting a thread or stack frame in the Threads view will update all windows (source, variables, registers).
llvm-svn: 234640
Summary:
Previously the Debugger::HandleProcessEvent hid a top IOHandler if the
process's IOHandler was inactive and later refreshed it. Usually the
IOHandler.Refresh() prints the (lldb) prompt. The problem was in case of
iOS remote platform when trying to execute 'command source' command.
On this platform the process's IOHandler is empty, therefore the
Debugger::HandleProcessEvent hid a top IOHandler and later refreshed it.
So that the (lldb) prompt was printed with a program output in mixed
order:
was:
```
longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
longlonglonglonglonglonglonglonglonglonglonglonglonglonglon(lldb)
glonglonglonglonglonglonglonglonglonglonglonglong string
```
now:
```
longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
longlonglonglonglonglonglonglonglong string
```
Reviewers: zturner, jingham, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, jingham, zturner, clayborg
Differential Revision: http://reviews.llvm.org/D8929
llvm-svn: 234517
In an effort to reduce binary size for components not wishing to
link against all of LLDB, as well as a parallel effort to reduce
link dependencies on Python, this patch splits out the notion of
LLDB initialization into "full" and "common" initialization.
All code related to initializing the full LLDB suite lives directly
in API now. Previously it was only referenced from API, but because
it was defined in lldbCore, it would get implicitly linked against
by everything including lldb-server, causing a considerable
increase in binary size.
By moving this to the API layer, it also creates a better layering
for the ongoing effort to make the embedded interpreter replacable
with one from a different language (or even be completely removeable).
One semantic change necessary to get this all working was to remove
the notion of a shared debugger refcount. The debugger is either
initialized or uninitialized now, and calling Initialize() multiple
times will simply have no effect, while the first Terminate() will
now shut it down no matter how many times Initialize() was called.
This behaves nicely with all of our supported usage patterns though,
and allows us to fix a number of nasty hacks from before.
Differential Revision: http://reviews.llvm.org/D8462
llvm-svn: 233758
I am fixing this by:
1 - make sure we aren't trying to set the symbol file for a module to the same thing it already has and leaving it alone if it is the same
2 - keep all old symbol files around in the module in case there are any outstanding type references
<rdar://problem/18029116>
llvm-svn: 233757
A char can have signed and unsigned encoding but previously lldb always
assumed it is signed. This CL adds a logic to detect the encoding of
'char' types based on the default encoding on the target architecture.
It fixes variable printing and expression evaluation on architectures
where 'char' is signed by default.
Differential revision: http://reviews.llvm.org/D8636
llvm-svn: 233682
Summary:
Presently, if a log file already exists, lldb simply starts overwriting bits of it, without
truncating or anything. This patch makes it use eFileOptionFileTruncate by default. It also adds
an --append option, which will append to the file without truncating. A test is included.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8450
llvm-svn: 232801
This creates a new top-level folder called Initialization which
is intended to hold code specific to LLDB system initialization.
Currently this holds the Initialize() and Terminate() functions,
as well as the fatal error handler.
This provides a means to break the massive dependency cycle which
is caused by the fact that Debugger depends on Initialize and
Terminate which then depends on the entire LLDB project. With
this structure, it will be possible for applications to invoke
lldb_private::Initialize() directly, and have that invoke
Debugger::Initialize.
llvm-svn: 232768
Specifically, there were some functions for converting enums
to strings and a function for matching a string using a specific
matching algorithm. This moves those functions to more appropriate
headers in lldb/Utility and updates references to include the
new headers.
llvm-svn: 232673
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 removes ScriptInterpreterObject from the codebase completely.
Places that used to rely on ScriptInterpreterObject now use
StructuredData::Object and its derived classes. To support this,
a new type of StructuredData object is introduced, called
StructuredData::Generic, which stores a void*. Internally within
the python library, StructuredPythonObject subclasses this
StructuredData::Generic class so that it can addref and decref
the python object on construction and destruction.
Additionally, all of the classes in PythonDataObjects.h such
as PythonList, PythonDictionary, etc now provide a method to
create an instance of the corresponding StructuredData type. For
example, there is PythonDictionary::CreateStructuredDictionary.
To eliminate dependencies on PythonDataObjects for external
callers, all ScriptInterpreter methods now return only
StructuredData classes
The rest of the changes in this CL are focused on fixing up
users of PythonDataObjects classes to use the new StructuredData
classes.
llvm-svn: 232534
Summary:
There was a race condition regarding the output of the inferior process. The reading of the
output is performed on a separate thread, and there was no guarantee that the output will get
eventually consumed. Because of that, it was happening that calling Process::GetSTDOUT was not
returning anything even though the process was terminated and would definitely not produce any
further output. This was usually happening only under very heavy system load, but it can be
reproduced by placing an usleep in the stdio thread (Process::STDIOReadThreadBytesReceived).
This patch addresses this by adding synchronization capabilities to the Communication thread.
After calling Communication::SynchronizeWithReadThread one can be sure that all pending input has
been processed by the read thread. This function is then called after every public event which
stops the process to obtain the entire process output.
Test Plan: TestProcessIO.py should now succeed every time instead of flaking in and out.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8246
llvm-svn: 232023
After http://reviews.llvm.org/D8133 landed as r231550 process launch on remote platform stopped working.
This adds Debugger::InitializeForLLGS and tracks whether one or both of Initialize and InitializeForLLGS have been called, calling only the corresponding lldb_private::Terminate* methods as necessary. Since lldb_private::Terminate calls lldb_private::TerminateForLLGS, the latter method may be called twice if Initialize was called for both however the terminate methods ensure they are only called once after being initialized.
This still maintains the reduced binary size, though it does now technically link in lldb_private::Terminate on lldb-server even though this should never be called.
This should resolve the issue raised in http://reviews.llvm.org/D8133 where Debugger::Terminate assumed that there were 0 references to debugger and terminated early.
Differential Revision: http://reviews.llvm.org/D8183
llvm-svn: 231808
This removes Host::Backtrace from the codebase, and changes all
call sites to use llvm::sys::PrintStackTrace(). This makes the
functionality available for all platforms, and even for platforms
which currently had a supported implementation of Host::Backtrace,
this patch should enable richer information in stack traces, such
as file and line number information, as well as giving it the
ability to unwind through inlined functions.
llvm-svn: 231511
This is part of a larger effort to reduce header file footprints.
Combined, these patches reduce the build time of LLDB locally by
over 30%. However, they touch many files and make many changes,
so will be submitted in small incremental pieces.
Reviewed By: Greg Clayton
Differential Revision: http://reviews.llvm.org/D8022
llvm-svn: 231097
Summary:
The code for GetSyntheticArrayMemberFromPointer and
GetSyntheticArrayMemberFromArray was identical, so just collapse the
the methods into one.
Reviewers: granata.enrico, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7911
llvm-svn: 230708
Summary:
http://llvm.org/bugs/show_bug.cgi?id=20400
The default triple of i686-pc-linux-gnu for 32 bit linux targets is compatible
but not necessarily identical to the inferior binaries.
Applying Azat Khuzhin's solution of using ArchSpec::IsCompatibleMatch() instead
of ArchSpec::IsExactMatch() when comparing ObjectFile and Modules architecture.
Reviewers: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7897
llvm-svn: 230694
llvm::StringRef doesn't make a copy of a string, it just holds a
reference. When special_directions_stream went out of scope,
special_directions was holding on to a stale pointer.
Moving special_directions_stream into a higher scope to keep
special_directions pointing to a valid string.
llvm-svn: 229767
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
There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime.
Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use.
llvm-svn: 228892
A runtime support value is a ValueObject whose only purpose is to support some language runtime's operation, but it does not directly provide any user-visible benefit
As such, unless the user is working on the runtime support, it is mostly safe for them not to see such a value when debugging
It is a language runtime's job to check whether a ValueObject is a support value, and that - in conjunction with a target setting - is used by frame variable and target variable
SBFrame::GetVariables gets a new overload with yet another flag to dictate whether to return those support values to the caller - that which defaults to the setting's value
rdar://problem/15539930
llvm-svn: 228791
only execute thumb instructions, force the arch triple string to
be "thumbv..." instead of "armv..." so we do the right thing by
default when disassembling arbitrary chunks of code.
<rdar://problem/15126397>
llvm-svn: 228486
