| Age | Commit message (Collapse) | Author |
|---|
|
The `lldbassert` macro in LLDB behaves like a regular `assert` when
assertions are enabled, and otherwise prints a pretty backtrace and
prompts the user to file a bug. By default, this is emitted as a
diagnostic event, but vendors can provide their own behavior, for
example pre-populating a bug report.
Recently, we ran into an issue where an `lldbassert` (in the Swift
language plugin) would fire excessively, to the point that it was
interfering with the usability of the debugger.
Once an `lldbasser` has fired, there's no point in bothering the user
over and over again for the same problem. This PR solves the problem by
introducing a static `std::once_flag` in the macro. This way, every
`lldbasser` will fire at most once per lldb instance.
rdar://148520448
|
|
Include the LLDB version in the lldbassert error message, and prompt
users to include it in the bug report. The majority of users that bother
filing a bug report just copy past the stack trace and often forget to
include this important detail. By putting it after the backtrace and
before the prompt, I'm hoping it'll get copy-pasted in.
rdar://146793016
|
|
Revert to the state after d7796855b879 and use the underlying buffer
directly. I was still under the impression that was unsafe, so I did a
drive-by fix, which this commit reverts.
|
|
Rename `lldb_assert` to `_lldb_assert` to make it more obvious that you
shouldn't be using this function directly. Instead, you should use the
`lldbassert` macro which becomes a regular assert in a debug/asserts
build.
|
|
As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly
( 65b13610a5226b84889b923bae884ba395ad084d for further reference )
* Don't call raw_string_ostream::flush(), which is essentially a no-op.
* Avoid unneeded calls to raw_string_ostream::str(), to avoid excess
indirection.
|
|
|
|
When hitting an lldbassert in a non-assert build, we emit a blurb
including the assertion, the triggering file and line and a pretty
backtrace leading up to the issue. Currently, this is all printed to
stderr. That's fine on the command line, but when used as library, for
example from Xcode, this information doesn't make it to the user. This
patch uses the diagnostic infrastructure to report LLDB asserts as
diagnostic events.
The patch is slightly more complicated than I would've liked because of
layering. lldbassert is part of Utility while the debugger diagnostics
are implemented in Core.
Differential revision: https://reviews.llvm.org/D152866
|
|
Whether assertions are enabled or not is orthogonal to the build type
which could lead to surprising behavior for lldbassert. Previously, when
doing a debug build with assertions disabled, lldbassert would become a
NOOP, rather than printing an error like it does in a release build. By
definining lldbassert in terms of NDEBUG, it behaves like a regular
assert when assertions are enabled, and like a soft assert.
Differential revision: https://reviews.llvm.org/D150639
|
|
This distinction doesn't matter for an in-tree build, but when building
against an installed llvm, only the former is present.
This should fix the LLDB Standalone bot:
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/
|
|
Call `os_log_fault` when an lldb assert fails. We piggyback off
`LLVM_SUPPORT_XCODE_SIGNPOSTS`, which also depends on `os_log`, to avoid
having to introduce another CMake check and corresponding define.
This patch also adds a small test using lldb-test that verifies we abort
with a "regular" assertion when asserts are enabled.
Differential revision: https://reviews.llvm.org/D98987
|
|
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
|
|
llvm_unreachable is marked noreturn so the compiler can assume the code
for printing the error message in release builds isn't hit which defeats
the purpose.
|
|
As per Davide's suggestion offline.
llvm-svn: 365250
|
|
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
|
|
rdar://problem/49356014
Differential Revision: https://reviews.llvm.org/D59911
llvm-svn: 357268
|
|
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
|
|
Reviewers: JDevlieghere, teemperor, #lldb
Reviewed By: JDevlieghere
Subscribers: clayborg, lemo, lldb-commits
Differential Revision: https://reviews.llvm.org/D51604
llvm-svn: 341387
|
|
This patch makes adjustments to header file includes in
lldbUtility based on recommendations by the iwyu tool
(include-what-you-use). The goal here is to make sure that
all files include the exact set of headers which are needed
for that file only, to eliminate cases of dead includes (e.g.
someone deleted some code but forgot to delete the header
includes that that code necessitated), and to eliminate the
case where header includes are picked up transitively.
llvm-svn: 299676
|
|
*** 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
|
|
Summary:
This changes lldb_assert to accept bool expressions as the parameter, this is because some
objects (such as std::shared_ptr) are convertible to bool, but are not convertible to int, which
leads to surprising errors.
Reviewers: granata.enrico, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9565
llvm-svn: 236819
|
|
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
|
|
We would like it if LLDB never crashed, especially if we never caused LLDB to crash
On the other hand, having assertions can sometimes be useful
lldbassert(x) is the best of both worlds:
- in debug builds, it turns into a regular assert, which is fine because we don't mind debug LLDB to crash on development machines
- in non-debug builds, it emits a message formatted just like assert(x) would, but then instead of crashing, it dumps a backtrace, suggests filing a bug, and keeps running
llvm-svn: 231310
|
