| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 274277
|
|
|
|
|
|
| |
http://reviews.llvm.org/D21770
llvm-svn: 274256
|
|
|
|
|
|
| |
<rdar://problem/24306284>
llvm-svn: 274254
|
|
|
|
|
|
|
| |
I overlooked the possibility of certain targets translating increment statement into a read and write.
In this case we replace increment statement with an assignment.
llvm-svn: 274215
|
|
|
|
|
|
| |
Fixes rdar://27002512
llvm-svn: 274164
|
|
|
|
|
|
| |
- OptionArgElement can potentially use negative indices to mean interesting, but non option, states
llvm-svn: 274159
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This removes the last usage of Platform plugins in lldb-server -- it was used for launching child
processes, where it can be trivially replaced by Host::LaunchProces (as lldb-server is always
running on the host).
Removing platform plugins enables us to remove a lot of other unused code, which was pulled in as
a transitive dependency, and it reduces lldb-server size by 4%--9% (depending on build type and
architecture).
Reviewers: clayborg
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D20440
llvm-svn: 274125
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain.
Summary : The problem appears while linking liblldb.so. The class Address contain atomic variable m_offset. The loading and storing of variable is access via atomic_load_8 and atomic_store_8 functions. Some target fail to implicitly link libatomic, which cause undefine reference to atomic_store_8/atomic_load_8. This patch uses http://reviews.llvm.org/D20896 to check if libatomic need to be explicitly link.
Reviewed by labath.
Differential: D20464
llvm-svn: 274121
|
|
|
|
| |
llvm-svn: 274116
|
|
|
|
|
|
|
|
| |
now they are.
<rdar://problem/27002247>
llvm-svn: 274037
|
|
|
|
|
|
|
|
|
|
| |
stop the
process.
<rdar://problem/26990309>
llvm-svn: 274032
|
|
|
|
|
|
| |
<rdar://problem/26998596>
llvm-svn: 273979
|
|
|
|
|
|
|
|
|
|
|
| |
execution context now that the @lldb.command decorator does the right thing for the command function that takes 5 arguments.
A few fixes:
- Check the process state to make sure it is stopped
- Grab the frame from the "exe_ctx" so this will work during breakpoint callbacks
- Print out the SBDeclaration objects of the variables that shadow each other so we can see the source locations of which variable declarations are shodowing each other.
llvm-svn: 273963
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Target::Install() was assuming the module at index 0 was the executable.
This is often true, but not guaranteed to be the case. The
TestInferiorChanged.py test highlighted this when run against iOS.
After the binary is replaced in the middle of the test, it becomes the
last module in the list. The rest of the Target::Install() logic then
clobbers the executable file by using whatever happens to be the first
module in the target module list.
This change also marks the TestInferiorChanged.py test as a no-debug-info
test.
llvm-svn: 273960
|
|
|
|
|
|
|
|
|
|
|
|
| |
explicit in how it adds the kernel binary, to guard against the
case where a kernel corefile might incorrectly include the kernel's
UUID in it (so calling ::GetSharedModule may end up returning the
global module cache's copy of the core file instead of adding the
kerenl binary).
<rdar://problem/26988816>
llvm-svn: 273954
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D21164
llvm-svn: 273869
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D21516
llvm-svn: 273863
|
|
|
|
|
|
|
|
|
|
| |
We were checking for integer types only before this. So I added the ability for CompilerType objects to check for integer and enum types.
Then I searched for places that were using the CompilerType::IsIntegerType(...) function. Many of these places also wanted to be checking for enumeration types as well, so I have fixed those places. These are in the ABI plug-ins where we are figuring out which arguments would go in where in regisers/stack when making a function call, or determining where the return value would live. The real fix for this is to use clang to compiler a CGFunctionInfo and then modify the code to be able to take the IR and a calling convention and have the backend answer the questions correctly for us so we don't need to create a really bad copy of the ABI in each plug-in, but that is beyond the scope of this bug fix.
Also added a test case to ensure this doesn't regress in the future.
llvm-svn: 273750
|
|
|
|
|
|
|
|
| |
up the new calls in SBProcess that give out SBMemoryRegionInfo and SBMemoryRegionInfoList objects.
Also make sure the right headers and .i files are included so SWIG can hook everything up.
llvm-svn: 273749
|
|
|
|
|
|
|
|
| |
type, since it actually doesn't resolve to the type of the class it points to
Fixes rdar://26535584
llvm-svn: 273721
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner, clayborg, tfiala
Subscribers: sas, lldb-commits
Differential Revision: http://reviews.llvm.org/D21648
llvm-svn: 273720
|
|
|
|
|
|
| |
<rdar://problem/17990991>
llvm-svn: 273718
|
|
|
|
|
|
|
|
| |
NSDictionary in the wrong order
Fixes rdar://26478641
llvm-svn: 273695
|
|
|
|
| |
llvm-svn: 273649
|
|
|
|
| |
llvm-svn: 273648
|
|
|
|
|
|
|
|
|
|
|
| |
5-argument version of the Python command function
This:
a) teaches PythonCallable to look inside a callable object
b) teaches PythonCallable to discover whether a callable method is bound
c) teaches lldb.command to dispatch to either the older 4 argument version or the newer 5 argument version
llvm-svn: 273640
|
|
|
|
|
|
| |
<rdar://problem/22039804>
llvm-svn: 273632
|
|
|
|
|
|
| |
<rdar://problem/26563587>
llvm-svn: 273622
|
|
|
|
|
|
| |
This shows how to grab individual blocks from stack frames and get only the variables from those blocks. It then will iterate over all of the parent blocks and look for shadowed variables.
llvm-svn: 273604
|
|
|
|
| |
llvm-svn: 273582
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds new SB API calls and classes to allow a user of the SB API to obtain a full list of memory regions accessible within the process. Adding this to the API makes it possible use the API for tasks like scanning memory for blocks allocated with a header and footer to track down memory leaks, otherwise just inspecting every address is impractical especially for 64 bit processes.
These changes only add the API itself and a base implementation of GetMemoryRegions() to lldb_private::Process::GetMemoryRegions.
I will submit separate patches to fill in lldb_private::Process::GetMemoryRegionInfoList and GetMemoryRegionInfo for individual platforms.
The original discussion about this is here:
http://lists.llvm.org/pipermail/lldb-dev/2016-May/010203.html
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20565
llvm-svn: 273547
|
|
|
|
| |
llvm-svn: 273546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain.
This patch contains 2 changes:
- Corrected target address calculation of compact branch instructions to reflect changes in disassembler (http://reviews.llvm.org/D17540).
- Added emulation for (missing) 'Addiu' instruction.
Reviewers :jaydeep, bhushan, clayborg
Differential: http://reviews.llvm.org/D21064
llvm-svn: 273535
|
|
|
|
|
|
|
|
| |
for TestNamespaceLookup.py; didn't see anything obviously wrong so I'll
need to look at this more closely before re-committing. (passed OK on
macOS ;)
llvm-svn: 273531
|
|
|
|
|
|
|
|
|
| |
There's uses of "macosx" that will be more tricky to
change, like in triples (e.g. "x86_64-apple-macosx10.11") -
for now I'm just updating source comments and strings printed
for humans.
llvm-svn: 273524
|
|
|
|
|
|
| |
<rdar://problem/26935520>
llvm-svn: 273445
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds a new Xcode variable, LLDB_ENABLE_COVERAGE.
If set to 1, then the Xcode build will produce a clang
coverage-style build of LLDB. This can be done with a commandline
invocation such as:
xcodebuild -scheme desktop -configuration Debug build LLDB_ENABLE_COVERAGE=1
Alternatively, the variable can be locally modified from within Xcode
and built with the Xcode IDE.
llvm-svn: 273332
|
|
|
|
|
|
|
|
|
|
| |
In Address.cpp, we were asking for the lldb::eSymbolContextVariable to be resolved, yet we weren't using the variable. This code gets called when disassembling and can cause the manual creation of all global variables variables which can take minutes. Removing eSymbolContextVariable allows disassembly to not create these long pauses.
In Module.cpp, if someone only specified the lldb::eSymbolContextVariable flag, we would not look into a module's debug info, now we will.
<rdar://problem/26907449>
llvm-svn: 273307
|
|
|
|
|
|
| |
were making things not build due to header file issues with stdio.h.
llvm-svn: 273306
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which doesn't like against all the extra UI frameworks on ios)
so it now generates a binary called "debugserver-nonui" and puts
it in /usr/local/bin instead of /Developer/usr/bin.
Add some cruft to RNBDefs.h to get the version number (provided
by Xcode at build time) with either the name "debugserver" or
"debugserver_nonui" as appropriate.
Add the "debugserver-mini" target to the top level "ios" target
in lldb xcode project file, so this nonui debugserver will be
built along with the normal lldb / debugserver.
<rdar://problem/24730789>
llvm-svn: 273236
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fix capitalization
Reviewers: labath, sas, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D21422
llvm-svn: 273225
|
|
|
|
|
|
| |
This test is currently failing. We have a bug for it, as noted.
llvm-svn: 273211
|
|
|
|
|
|
|
|
|
|
|
|
| |
AArch64 targets
This patch allows LLDB for AArch64 to watch all bytes, words or double words individually on non 8-byte alligned addresses.
This patch also adds tests to verify this functionality.
Differential revision: http://reviews.llvm.org/D21280
llvm-svn: 272916
|
|
|
|
|
|
|
| |
Tracked by:
https://llvm.org/bugs/show_bug.cgi?id=28156
llvm-svn: 272902
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not sure what changed, but something outside our code
is failing one of the EditLine gtests on OS X CI (and
locally) before the gtest ever gets to run. This fails
the first EditLine gtest.
This change exports the TERM as "vt100" before running
the lldb-gtest binary, fixing the issue.
llvm-svn: 272844
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During expression evaluation, the ClangExpressionParser preforms a
number of hard-coded fixups on the expression's IR before the module
is assembled and dispatched to be run in a ThreadPlan.
This patch allows the runtimes to register LLVM passes to be run over the
generated IR, that they may perform language or architecture-specfic fixups
or analyses over the generated expression.
This makes expression evaluation for plugins more flexible and allows
language-specific fixes to reside in their own module, rather than
littering the expression evaluator itself with language-specific fixes.
llvm-svn: 272800
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://reviews.llvm.org/D21211
If gtest tests of lldb fail, there are no test results for Jenkins to
consume. This will make the results of the gtest failure available to
Jenkins.
This is to address the failure visible in:
http://lab.llvm.org:8080/green/job/lldb_build_test/19196/
llvm-svn: 272751
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This removes the last usage of the Platform plugin in NPL. It was being
used for determining the architecture of the debugged process. I replace
the call that went through the Platform plugin with a lower level call
on the ObjectFile directly.
Reviewers: tberghammer
Subscribers: uweigand, nitesh.jain, omjavaid, lldb-commits
Differential Revision: http://reviews.llvm.org/D21324
llvm-svn: 272686
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes various races between the time the private state thread is signaled to exit and the time it actually exits (during which it no longer responds to events). Previously, this was consistently causing 2-second timeout delays on process detach/stop for us.
This also prevents crashes that were caused by the thread controlling its own owning pointer while the controller was using it (copying the thread wrapper is not enough to mitigate this, since the internal thread object was getting reset anyway). Again, we were seeing this consistently.
Differential Revision: http://reviews.llvm.org/D21296
llvm-svn: 272682
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PlatformRemoteAppleTV to check the target.exec-search-paths
directories for files after looking in the SDK. An additional
wrinkle is that the remote file path may be something like
".../UIFoundation.framework/UIFoundation" and in
target.exec-search-paths we will have "UIFoundation.framework".
Looking for just the filename of the path is not sufficient -
we need to also look for it by the parent directories because
this may be a darwin bundle/framework like the UIFoundation
example.
We really need to make a PlatformRemoteAppleDevice and have
PlatformRemoteiOS, PlatformRemoteAppleWatch, and PlatformRemoteAppleTV
inherit from it. These three classes are 98% identical code.
<rdar://problem/25976619>
llvm-svn: 272635
|