| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
CMake's framework target generation was unable to generate POST_BUILD steps (see: https://gitlab.kitware.com/cmake/cmake/issues/16363).
It turns out working around this is really not reasonable. The more reasonable solution to me is just to not support LLDB.framework unless you are on CMake 3.7 or newer.
Since CMake 3.7.1 is released that's how I'm going to handle this.
llvm-svn: 289841
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: I was building lldb using cross mingw-w64 toolchain on Linux and observed some issues. This is first patch in the series to fix that build. It mostly corrects the case of include files and adjusts some #ifdefs from _MSC_VER to _WIN32 and vice versa. I built lldb on windows with VS after applying this patch to make sure it does not break the build there.
Reviewers: zturner, labath, abidh
Subscribers: ki.stfu, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D27759
llvm-svn: 289821
|
|
|
|
|
|
|
|
|
| |
This code is currently unused.
Removing it should make porting of the linux plugin to NetBSD easier, and we can
always add it later if needed.
llvm-svn: 289801
|
|
|
|
| |
llvm-svn: 289746
|
|
|
|
|
|
|
|
|
|
| |
LLDB needs some minor changes to adopt PrettyStackTrace after https://reviews.llvm.org/D27683.
We remove our own SetCrashDescription() function and use LLVM-provided RAII objects instead.
We also make sure LLDB doesn't define __crashtracer_info__ which would collide with LLVM's definition.
Differential Revision: https://reviews.llvm.org/D27735
llvm-svn: 289711
|
|
|
|
| |
llvm-svn: 289695
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.
Differential Revision: https://reviews.llvm.org/D26671
llvm-svn: 289647
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This code was probably needed to support VS2013 and is not needed now. I have built it with VS and mingw. Ok to remove it?
Reviewers: zturner, abidh
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D27707
llvm-svn: 289644
|
|
|
|
| |
llvm-svn: 289520
|
|
|
|
| |
llvm-svn: 289518
|
|
|
|
|
|
|
|
|
|
| |
I'm transitioning away from my current employer, and I do not foresee myself
spending much time on LLDB in the near future. Ideally somebody on the Google
Android team takes over the gdb-remote protocol tests, and somebody with decent
familiarity with the test suite infrastructure takes over the parallel test
runner and test event stream portions of the Python test suite.
llvm-svn: 289479
|
|
|
|
|
|
|
| |
The test passes on linux. The i386 case is already handled by
skipIfHostIncompatibleWithRemote.
llvm-svn: 289427
|
|
|
|
|
|
|
|
|
|
| |
empty objective C types from the runtime.
We don't parse ObjC v1 types from the runtime metadata like we do for ObjC v2, but doing so by creating empty types was ruining the i386 v1 debugging experience.
<rdar://problem/24093343>
llvm-svn: 289233
|
|
|
|
|
|
| |
that TestMultipleDebuggers.py has.
llvm-svn: 289223
|
|
|
|
| |
llvm-svn: 289222
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: jingham
Subscribers: jaydeep, bhushan, slthakur, lldb-commits
Differential Revision: https://reviews.llvm.org/D27124
llvm-svn: 289211
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg, labath, zturner
Subscribers: jaydeep, bhushan, slthakur, lldb-commits
Differential Revision: https://reviews.llvm.org/D27085
llvm-svn: 289210
|
|
|
|
|
|
|
|
|
|
|
|
| |
qprocessInfo packet.
Reviewers: jaydeep, bhushan, clayborg
Subscribers: slthakur, lldb-commits
Differential Revision: https://reviews.llvm.org/D26542
llvm-svn: 289209
|
|
|
|
|
|
|
|
|
| |
This test links against liblldb, so it can only run when the target arch is the
same arch as liblldb. We already have a decorator for that, so apply it.
While I'm in there, also mark the test as debug-info independent.
llvm-svn: 289199
|
|
|
|
| |
llvm-svn: 289188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crashing LLDB.
I found the race condition in:
ScriptInterpreter *CommandInterpreter::GetScriptInterpreter(bool can_create);
More than one "ScriptInterpreter *" was being returned due to the race which caused any clients with the first one to now be pointing to freed memory and we would quickly crash.
Added a test to catch this so we don't regress.
<rdar://problem/28356584>
llvm-svn: 289169
|
|
|
|
|
|
|
| |
Hopefully these will all disappear in the future once we move
to formatv.
llvm-svn: 289168
|
|
|
|
| |
llvm-svn: 289164
|
|
|
|
| |
llvm-svn: 289155
|
|
|
|
|
|
|
|
|
|
| |
ThreadList had an assignment operator that didn't lock the "rhs" thread list object. This means a thread list can be mutated while it is being copied.
The copy constructor calls the assignment operator as well. So this fixes the unsafe threaded access to ThreadList which we believe is responsible for a lot of crashes.
<rdar://problem/28075793>
llvm-svn: 289100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to not be set by Process::WillPublicStop() so the driver won't get
access to them. The fix is straightforward, moving the call to
WillPublicStop above the early return for the interrupt case. (the
interrupt case does an early return because the rest of the function
is concerned with running stop hooks etc and those are not applicable
when we've interrupted the process).
Also added a test case for it. The test case is a little complicated
because I needed to drive lldb asynchronously to give the program
a chance to get up and running before I interrupt it. Running to
a breakpoint was not sufficient to catch this bug.
<rdar://problem/22693778>
llvm-svn: 289026
|
|
|
|
|
|
| |
to match other timeouts.
llvm-svn: 289023
|
|
|
|
|
|
|
| |
of using the address of the all_image_infos struct.
<rdar://problem/29547847>
llvm-svn: 289016
|
|
|
|
|
|
|
|
| |
In the process, discovered a bug related to the use of an
uninitialized-pointer, and fixed as suggested by Enrico
in an lldb-dev mailing list thread.
llvm-svn: 289015
|
|
|
|
| |
llvm-svn: 289012
|
|
|
|
| |
llvm-svn: 289009
|
|
|
|
|
|
| |
<rdar://problem/29191857>
llvm-svn: 289006
|
|
|
|
| |
llvm-svn: 289000
|
|
|
|
|
|
| |
the version that needed a StringRef as the URL, and also updated all virtual functions to say "override" to make sure this doesn't happen again.
llvm-svn: 288999
|
|
|
|
| |
llvm-svn: 288797
|
|
|
|
|
|
| |
LLVM build trees export the gtest library through a special export set. If you're building against a build tree you shouldn't need to re-add gtest, but if you're building against an installed LLVM you do.
llvm-svn: 288691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This diff
1. Adds a comment to ObjectFileELF.cpp about the current
approach to determining the OS.
2. Replaces the check in SymbolFileDWARF.cpp with a more robust one.
Test plan:
Built (on Linux) a test binary linked to a c++ shared library
which contains just an implementation of a function TestFunction,
the library (the binary itself) doesn't contain ELF notes
and EI_OSABI is set to System V.
Checked in lldb that now "p TestFunction()" works fine
(and doesn't work without this patch).
Differential revision: https://reviews.llvm.org/D27380
llvm-svn: 288687
|
|
|
|
|
|
|
| |
This file is not in the include path when building with a non-standalone
toolchain. In does not seem to be necessary anyway.
llvm-svn: 288674
|
|
|
|
| |
llvm-svn: 288673
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rationale:
scripts/Python/modules: android is excluded at a higher level, so no point in
checking here
tools/lldb-mi: lldb-mi builds fine (with some cosmetic tweaks) on android, and
there is no reason it shouldn't.
tools/lldb-server: LLDB_DISABLE_LIBEDIT/CURSES already take the platform into
account, so there is no point in checking again.
I am reasonably confident this should not break the build on any platform, but
I'll keep an eye out on the bots.
llvm-svn: 288661
|
|
|
|
|
|
| |
This is updating to take r288632 into account.
llvm-svn: 288633
|
|
|
|
|
|
| |
r288535.
llvm-svn: 288542
|
|
|
|
|
|
|
|
| |
In r288065, we added more report types into ASan that will be reported via the debugging API. This patch in LLDB provides human-friendly bug descriptions. This also improves wording on existing bug descriptions.
Differential Revision: https://reviews.llvm.org/D27017
llvm-svn: 288535
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This replaces all the uses of the __ANDROID_NDK__ define with __ANDROID__. This
is a preparatory step to remove our custom android toolchain file and rely on
the standard android NDK one instead, which does not provide this define.
Instead I rely, on __ANDROID__, which is set by the compiler.
I haven't yet removed the cmake variable with the same name, as we will need to
do something completely different there -- NDK toolchain defines
CMAKE_SYSTEM_NAME to Android, while our current one pretends it's linux.
Reviewers: tberghammer, zturner
Subscribers: danalbert, srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D27305
llvm-svn: 288494
|
|
|
|
|
|
| |
Should fix the bots.
llvm-svn: 288403
|
|
|
|
|
|
| |
This is no longer an issue with recent versions of the android ndk.
llvm-svn: 288387
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a longstanding issue where the expression parser does not handle wide CFStrings (e.g., @"凸凹") correctly, producing the useless error message
Internal error [IRForTarget]: An Objective-C constant string's string initializer is not an array
error: warning: expression result unused
error: The expression could not be prepared to run in the target
This is just a side effect of the fact that we don't handle wide string constants when converting these to CFStringCreateWithBytes. That function takes the string's encoding as an argument, so I made it work and added a testcase.
https://reviews.llvm.org/D27291
<rdar://problem/13190557>
llvm-svn: 288386
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The fix is to make sure llvm does not pull in dlopen() in configurations where it
is not available.
Reviewers: tberghammer, beanz
Subscribers: danalbert, srhines, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D26505
llvm-svn: 288331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Since the function is way too big already, I tried at least to factor out the
timeout computation stuff into a separate function. I've tried to make the new
code semantically equivalent, and it also makes sense when I look at it as a done
deal.
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D27258
llvm-svn: 288326
|
|
|
|
|
|
|
|
|
| |
DynamicLoaderDarwinKernel::SearchForKernelWithDebugHints
on 32-bit devices.
<rdar://problem/29423290>
llvm-svn: 288284
|