| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 365651
|
|
|
|
| |
llvm-svn: 365650
|
|
|
|
| |
llvm-svn: 365649
|
|
|
|
| |
llvm-svn: 365648
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There's a number of requirements for installing LLDB on macOS that are untypical for LLVM projects: use special install-prefix for LLDB.framework, ship headers and tools as framework resources, patch RPATHs, externalize debug-info to dSYM's and strip binaries with `-ST`. For some of it we could use `llvm_externalize_debuginfo()` in the past and just add special cases. However, this complicates the code for all projects and comes with the major drawback, that it adds all these actions at build-time, i.e. dSYM creation and stripping take a lot of time and don't make sense at build-time.
LLVM's distribution mechanism (https://llvm.org/docs/BuildingADistribution.html) appears to be the natural candidate to install LLDB. Based on D64399 (enable in standalone builds), this patch integrates framework installation with the distribution mechanism and adds custom stripping flags and dSYM creation at install-time. Unlike the abandoned D61952, it leaves build-tree binaries untouched, so there's no side-effects on testing. Potential install-order issues must be handled externally.
Please let me know what you think, while I run a few more tests and add remarks+documentation.
Reviewers: xiaobai, compnerd, JDevlieghere, davide, labath, mgorny
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64408
llvm-svn: 365617
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Enable `distribution` and `install-distribution` targets in LLDB standalone and pre-populate the cache accordingly on macOS.
Documentation for distribution builds is here: https://llvm.org/docs/BuildingADistribution.html
Reviewers: xiaobai, mgorny, JDevlieghere, davide, compnerd
Reviewed By: xiaobai, JDevlieghere
Subscribers: lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64399
llvm-svn: 365616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The custom lldb-framework target was meant to encapsulate all build steps that LLDB.framework needs on top of the ordinaly liblldb. In the end all of it happens in post-build steps, so we can do the same with liblldb and cut down another source of confusion.
Reviewers: xiaobai, JDevlieghere
Reviewed By: xiaobai, JDevlieghere
Subscribers: mgorny, lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64397
llvm-svn: 365615
|
|
|
|
| |
llvm-svn: 365593
|
|
|
|
|
|
|
| |
This reverts commit ed499a36b67cf46cbf66052cfe374c80a595f1c1 and addresses
a problem causing a Windows build bot to hang.
llvm-svn: 365592
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move checking pointer code block before accessing the pointer
This caused lldb to crash when testing on Android
Patch by Wanyi Ye!
Differential Revision: https://reviews.llvm.org/D64434
llvm-svn: 365567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixed `Android.rules` for running test suite on remote android
- the build configuration is not compatible with ndk structure, change it to link to static libc++
- generally clang should be able to use libc++ and will link against the right library, but some libc++ installations require the user manually link libc++abi.
- add flag `-lc++abi` to fix the test binary build failure
Added `skipIfTargetAndroid` `skipUnlessTargetAndroid` for better test support
- the `skipIfPlatform` method will ask `lldbplatformutil.getPlatform()` for platform info which is actually the os type, and //Android// is not os type but environment
- create this function to handle the android target condition
**To Run Test on Remote Android**
1 start lldb-server on your devices
2 run lldb-dotest with following configuration:
`./lldb-dotest --out-of-tree-debugserver --arch aarch64 --platform-name remote-android --platform-url connect://localhost:12345 --platform-working-dir /data/local/tmp/ --compiler your/ndk/clang`
Reviewers: xiaobai, labath
Reviewed By: labath
Subscribers: labath, javed.absar, kristof.beyls, srhines, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64118
llvm-svn: 365561
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Replaces references to svn commits with the lldb version number those commits first appeared in. Themotivation is to show that these features are no longer that new and can generally be adopted.
Reviewers: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61778
llvm-svn: 365559
|
|
|
|
|
|
| |
ErrorHandling.h does not include WindowsError.h which is needed for mapWindowsError
llvm-svn: 365533
|
|
|
|
|
|
| |
This test was originally marked as expected failure on Windows, but it is timing out instead of outright failing now. The expectedFailure attribute does not correctly track timeouts (as in, they don't count as failures), so now this is causing the test suite to fail.
llvm-svn: 365527
|
|
|
|
|
|
| |
function signature
llvm-svn: 365526
|
|
|
|
| |
llvm-svn: 365459
|
|
|
|
| |
llvm-svn: 365458
|
|
|
|
| |
llvm-svn: 365457
|
|
|
|
| |
llvm-svn: 365421
|
|
|
|
|
|
| |
Include ErrorHandling.h for mapWindowsError.
llvm-svn: 365420
|
|
|
|
|
|
|
|
|
| |
The functions in read_plist() want bytes as input, not
strings.
<rdar://problem/52600712>
llvm-svn: 365416
|
|
|
|
|
|
| |
Address post-commit feedback from Pavel and Jim.
llvm-svn: 365403
|
|
|
|
|
|
| |
This is possible now that the function returns an llvm::Expected
llvm-svn: 365400
|
|
|
|
|
|
|
|
| |
After discussing this internally, it is my understanding this was used
for building LLDB internally at Apple, and is no longer used or
necessary.
llvm-svn: 365392
|
|
|
|
|
|
|
|
|
| |
As discussed offline, this tool is no longer used or maintained, and
doesn't provide the right abstraction for performance tracking in lldb.
Differential revision: https://reviews.llvm.org/D64362
llvm-svn: 365391
|
|
|
|
|
|
|
| |
Create a std::error_code from the result of GetLastError, which in turn
we can use to return an llvm::Error.
llvm-svn: 365390
|
|
|
|
|
|
|
|
| |
LaunchThread interface to return an expected
A couple of the function signatures changed and they were not updated in the Windows HostProcess
llvm-svn: 365388
|
|
|
|
|
|
|
|
| |
This reverts commit 9c01eaff6aa3f59d91530f47b85bb470377a7780.
The changes in this commit are causing several of the LLDB tests to hang and/or timeout.
llvm-svn: 365371
|
|
|
|
|
|
| |
Add missing interface changes after r365295.
llvm-svn: 365358
|
|
|
|
| |
llvm-svn: 365344
|
|
|
|
| |
llvm-svn: 365338
|
|
|
|
|
|
| |
Fixes Linux build errors after D64163/r365226
llvm-svn: 365295
|
|
|
|
|
|
|
|
| |
The Windows build currently cannot support debugging foreign targets or
debugging Windows ARM NT and Windows ARM64 targets. Do not assume a
x64/x86 host. This enables building lldb for Windows ARM64.
llvm-svn: 365282
|
|
|
|
|
|
| |
As per Davide's suggestion offline.
llvm-svn: 365250
|
|
|
|
|
|
|
| |
We could VerifyDecl sometimes with a nullptr. It would be nice if we
could get an actual assert here instead of triggering UB.
llvm-svn: 365247
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had a long discussion in D59911 about lldb_assert and what it means.
The result was the assert manifesto on lldb.llvm.org.
> LLDB provides lldb_assert() as a soft alternative to cover the middle
> ground of situations that indicate a recoverable bug in LLDB. In a
> Debug configuration lldb_assert() behaves like assert(). In a Release
> configuration it will print a warning and encourage the user to file a
> bug report, similar to LLVM’s crash handler, and then return
> execution.
However, currently lldb_assert doesn't behave they way it's being
described there: it doesn't abort in a debug/assert build. This patch
fixes that by adding a call to assert() in lldb_assert().
Differential revision: https://reviews.llvm.org/D64267#1571962
llvm-svn: 365246
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: teemperor, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64265
llvm-svn: 365243
|
|
|
|
|
|
|
|
|
| |
Change the interface to return an expected, instead of taking a Status
pointer.
Differential revision: https://reviews.llvm.org/D64163
llvm-svn: 365226
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we call this function with a non-namespace as a second argument (and a nullptr name), we currently
only get a nullptr as a return when we hit the "Bad!!!" code path. This patch just adds an assert as this
seems to be a programming error in the calling code.
Reviewers: shafik
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D57880
llvm-svn: 365157
|
|
|
|
|
|
|
|
|
|
| |
Rather than relying on `sizeof(void *)` to determine the architecture,
use the `CMAKE_SYSTEM_PROCESSOR` variable. This should allow us to
build for Windows and cross-compile. Without this, we would attempt to
build the x64 plugin on ARM64 which would fail due to the `CONTEXT` type
being defined for ARM64 rather than `x64`.
llvm-svn: 365155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch modernizes the GetSDKVersion API and hopefully prevents problems such as the ones discovered in D61218.
Reviewers: aprantl, jasonmolenda, clayborg
Reviewed By: aprantl, clayborg
Subscribers: clayborg, labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61233
llvm-svn: 365090
|
|
|
|
| |
llvm-svn: 365086
|
|
|
|
|
|
|
| |
Given that we use Ninja as the build system in the instructions below,
we might as well use it to build the documentation as well.
llvm-svn: 365083
|
|
|
|
|
|
|
| |
The file's content is part of the website:
https://lldb.llvm.org/resources/build.html
llvm-svn: 365082
|
|
|
|
|
|
|
|
|
|
| |
The current build instructions are structured according the host
platform. Instead of having instructions on how to build with CMake
repeated for every platform, I unified them, using subsections if things
are different for between platforms. I also added the code signing
instructions, which were hidden in a text file in the repository.
llvm-svn: 365081
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This option allow the toggling of the libraries-svr4 usage in ProcessGDBRemote. It's a follow up of https://reviews.llvm.org/D62503#1564296 and it's meant to test / tweak this new packet with, hopefully, minimum impact and in a faster way.
Enable it with `settings set plugin.process.gdb-remote.use-libraries-svr4 true`. For now, by default it's false.
I didn't put tests up for this but I did test it manually.
Reviewers: labath, jankratochvil
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64112
llvm-svn: 365059
|
|
|
|
|
|
|
|
| |
libc++abi became mandatory to link the libc++ binaries. LLDB only needs the build artifacts and not the linked output (we don't ship `libc++.dylib` and/or `libc++.a`). Disable the respective link steps to avoid the dependency to libc++abi.
<rdar://problem/51980716>
llvm-svn: 365038
|
|
|
|
|
|
|
|
|
|
| |
This was set in a std::function, but I was shadowing a
variable that I thought I was capturing. Even with this bug
we were correctly not raising an error and returning an address
of 0x0. We were not marking the symbol as weak, but apparently
the JIT didn't need that, so the test still passed.
llvm-svn: 364980
|
|
|
|
|
|
|
|
| |
framework on macOS, in line with the source/xcode project changes in
r364243.
<rdar://problem/49458356>
llvm-svn: 364979
|
|
|
|
| |
llvm-svn: 364976
|