If we're not touching them, we don't need to do anything special to pass
them along -- with one important caveat: due to how cmake arguments
work, the implicitly passed arguments need to be specified before
arguments that we handle.
This isn't particularly nice, but the alternative is enumerating all
arguments that can be used by llvm_add_library and the macros it calls
(it also relies on implicit passing of some arguments to
llvm_process_sources).
This implements coalescing of progress events using a timeout, as
discussed in the RFC on Discourse [1]. This PR consists of two commits
which, depending on the feedback, I may split up into two PRs. For now,
I think it's easier to review this as a whole.
1. The first commit introduces a new generic `Alarm` class. The class
lets you to schedule a function (callback) to be executed after a given
timeout expires. You can cancel and reset a callback before its
corresponding timeout expires. It achieves this with the help of a
worker thread that sleeps until the next timeout expires. The only
guarantee it provides is that your function is called no sooner than the
requested timeout. Because the callback is called directly from the
worker thread, a long running callback could potentially block the
worker thread. I intentionally kept the implementation as simple as
possible while addressing the needs for the `ProgressManager` use case.
If we want to rely on this somewhere else, we can reassess whether we
need to address those limitations.
2. The second commit uses the Alarm class to coalesce progress events.
To recap the Discourse discussion, when multiple progress events with
the same title execute in close succession, they get broadcast as one to
`eBroadcastBitProgressCategory`. The `ProgressManager` keeps track of
the in-flight progress events and when the refcount hits zero, the Alarm
class is used to schedule broadcasting the event. If a new progress
event comes in before the alarm fires, the alarm is reset (and the
process repeats when the new progress event ends). If no new event comes
in before the timeout expires, the progress event is broadcast.
[1]
https://discourse.llvm.org/t/rfc-improve-lldb-progress-reporting/75717/
Around this time last year, I said on the mailing list [1] that I wanted
to to transform the reproducers into something that resembles a
sysdiagnose on Apple platforms: a collection of files containing a
variety of information to help diagnose bugs or troubleshoot issues.
This patch adds that framework. Based on lessons learned from the
reproducers, I've intentionally tried to keep it small and simple.
Different parts of LLDB can register callbacks (this is necessary for
layering purposes) that will get called when the diagnostics should be
generated.
[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html
Differential revision: https://reviews.llvm.org/D134991
This patch removes the ability to instantiate the LLDB FileSystem class
with a FileCollector. It keeps the ability to collect files, but uses
the FileCollectorFileSystem to do that transparently.
Because the two are intertwined, this patch also removes the
finalization logic which copied the files over out of process.
This patch removes the ability to instantiate the LLDB FileSystem class
based on a VFS overlay. This also removes the "hack" where we cast the
VFS to a RedirectingFileSystem to obtain the external path. You can
still instantiate a FileSystem with a VFS, but with the caveat that
operations that rely on the external path won't work.
Differential revision: https://reviews.llvm.org/D120923
Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.
After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
Because of its dependency on clang (and potentially other compilers
downstream, such as swift) lldb_private::GetVersion already lives in its
own library called lldbBase. Despite that, its implementation was spread
across unrelated files. This patch improves things by introducing a
Version library with its own directory, header and implementation file.
The benefits of this patch include:
- We can get rid of the ugly quoting macros.
- Other parts of LLDB can read the version number from
lldb/Version/Version.inc.
- The implementation can be swapped out for tools like lldb-server than
don't need to depend on clang at all.
Differential revision: https://reviews.llvm.org/D115211
This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy and the modernize-use-default-member-init check.
$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix
This is a mass-refactoring patch and this commit will be added to
.git-blame-ignore-revs.
Differential revision: https://reviews.llvm.org/D103483
Our code for locating the shared library directory works via dladdr (or
the windows equivalent) to locate the path of an address known to reside
in liblldb. This works great for C++ programs, but there's a catch.
When (lib)lldb is used from python (like in our test suite), this dladdr
call will return a path to the _lldb.so (or such) file in the python
directory. To compensate for this, we have code which attempts to
resolve this symlink, to ensure we get the canonical location. However,
here's the second catch.
On windows, this file is not a symlink (but a copy), so this logic
fails. Since most of our other paths are derived from the liblldb
location, all of these paths will be wrong, when running the test suite.
One effect of this was the failure to find lldb-server in D96202.
To fix this issue, I add some windows-specific code to locate the
liblldb directory. Since it cannot rely on symlinks, it works by
manually walking the directory tree -- essentially doing the opposite of
what we do when computing the python directory.
To avoid python leaking back into the host code, I implement this with
the help of a callback which can be passed to HostInfo::Initialize in
order to assist with the directory location. The callback lives inside
the python plugin.
I also strenghten the existing path test to ensure the returned path is
the right one.
Differential Revision: https://reviews.llvm.org/D96779
This patch introduces a LLDB_SCOPED_TIMER macro to hide the needlessly
repetitive creation of scoped timers in LLDB. It's similar to the
LLDB_LOG(F) macro.
Differential revision: https://reviews.llvm.org/D93663
Extract all the provider related logic from Reproducer.h and move it
into its own header ReproducerProvider.h. These classes are seeing most
of the development these days and this reorganization reduces
incremental compilation from ~520 to ~110 files when making changes to
the new header.
When replaying the reproducer, lldb should source the .lldbinit file
that was captured by the reproducer and not the one in the current home
directory. This requires that we store the home directory as part of the
reproducer. By returning the virtual home directory during replay, we
ensure the correct virtual path gets constructed which the VFS can then
find and remap to the correct file in the reproducer root.
This patch adds a new HomeDirectoryProvider, similar to the existing
WorkingDirectoryProvider. As the home directory is not part of the VFS,
it is stored in LLDB's FileSystem instance.
The FileSystem initialization depends on the reproducer mode. It has
been growing organically to the point where it deserves its own helper
function. This also allows for early returns to simplify the code.
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
Pavel correctly pointed out that removing all control characters from
the working directory is overkill. It should be sufficient to just strip
the last ones.
llvm-svn: 375259
C++ defines two overloads of std::iscntrl. One in <cctype> and one in
<locale>. On linux we seem to include both which makes the std::erase_if
call ambiguous.
Wrap std::iscntrl call in a lambda to ensure regular overload
resolution.
llvm-svn: 375221
Now that the VFS knows how to deal with virtual working directories, we
can set the current working directory to the one we recorded during
reproducer capture. This ensures that relative paths are resolved
correctly during replay.
llvm-svn: 375064
Generally, reproducers are rev-locked to the version of LLDB, so it's
valuable to have the LLDB version in the reproducer. For now I just want
the information to be present, without enforcing it, but I envision
emitting a warning during replay in the future.
Differential revision: https://reviews.llvm.org/D63229
llvm-svn: 363225
This replaces the `info` typedef with a nested struct named Info. This
means we now have FooProvider and FooProvider::Info, instead of two
related but separate classes FooProvider and FooInfo. This change is
mostly cosmetic.
llvm-svn: 363211
The debug server does not need to use the instruction emulation. This
helps reduce the size of the final lldb-server binary by another ~100K
(~1% savings).
llvm-svn: 360067
The debug server does not need to use the instruction emulation. This helps
reduce the size of the final lldb-server binary by another ~100K (~1% savings).
llvm-svn: 359832
`_MSC_VER` indiciates that you are building with MSVC, not that you are building
for Windows. Use `_WIN32` (which identifies Win32 and Win64).
llvm-svn: 359817
This restructures the initialization path to move the ObjectContainer
initialization into the *full* initialization path. This is not needed
for the lldb-server initialization path. This helps strip off ~1MiB
from the binary.
llvm-svn: 359810
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.
Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.
I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.
Differential revision: https://reviews.llvm.org/D60508
llvm-svn: 358135
As per the discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html
This commit implements option (3):
> Go back to initializing the reproducer before the rest of the debugger.
> The method wouldn't be instrumented and guarantee no other SB methods are
> called or SB objects are constructed. The initialization then becomes part
> of the replay.
Differential revision: https://reviews.llvm.org/D58410
llvm-svn: 354631
This patch adds the file provider which is responsible for capturing
files used by LLDB.
When capturing a reproducer, we use a file collector that is very
similar to the one used in clang. For every file that we touch, we add
an entry with a mapping from its virtual to its real path. When we
decide to generate a reproducer we copy over the files and their
permission into to reproducer folder.
When replaying a reproducer, we load the VFS mapping and instantiate a
RedirectingFileSystem. The latter will transparently use the files
available in the reproducer.
I've tested this on two macOS machines with an artificial example.
Still, it is very likely that I missed some places where we (still) use
native file system calls. I'm hoping to flesh those out while testing
with more advanced examples. However, I will fix those things in
separate patches.
Differential revision: https://reviews.llvm.org/D54617
llvm-svn: 352538
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
This patch changes the way the reproducer is initialized. Rather than
making changes at run time we now do everything at initialization time.
To make this happen we had to introduce initializer options and their SB
variant. This allows us to tell the initializer that we're running in
reproducer capture/replay mode.
Because of this change we also had to alter our testing strategy. We
cannot reinitialize LLDB when using the dotest infrastructure. Instead
we use lit and invoke two instances of the driver.
Another consequence is that we can no longer enable capture or replay
through commands. This was bound to go away form the beginning, but I
had something in mind where you could enable/disable specific providers.
However this seems like it adds very little value right now so the
corresponding commands were removed.
Finally this change also means you now have to control this through the
driver, for which I replaced --reproducer with --capture and --replay to
differentiate between the two modes.
Differential revision: https://reviews.llvm.org/D55038
llvm-svn: 348152
This patch extends the FileSystem class with a bunch of functions that
are currently implemented as methods of the FileSpec class. These
methods will be removed in future commits and replaced by calls to the
file system.
The new functions are operated in terms of the virtual file system which
was recently moved from clang into LLVM so it could be reused in lldb.
Because the VFS is stateful, we turned the FileSystem class into a
singleton.
Differential revision: https://reviews.llvm.org/D53532
llvm-svn: 345783
We used to have a pretty stack trace printer in SystemInitializerCommon.
This was disabled on Apple because we didn't want the library to be
setting signal handlers, as this was causing issues when loaded into
Xcode. However, I think it's useful to have this for the LLDB driver, so
I moved it up to use the PrettyStackTraceProgram in the driver's main.
Differential revision: https://reviews.llvm.org/D49377
llvm-svn: 337261
Summary:
For lldb-server, it is sufficient to parse only the native object file
format for its target OS (no other file can be loaded into a running
process). This moves the object file initialization code into specific
initializer classes: lldb-test and liblldb get all object files;
lldb-server gets only one of them. For this to work, I've needed to
create a special SystemInitializer for use in lldb-server, instead of it
calling directly into the common one.
This reduces the size of lldb-server by about 2%, which is not
earth-shattering, but it's an easy win, and it helps.
Reviewers: zturner, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47250
llvm-svn: 333182
Summary:
Before this patch we were unable to write cross-platform MachO tests
because the parsing code did not compile on other platforms. The reason
for that was that ObjectFileMachO depended on
RegisterContextDarwin_arm(64)? (presumably for core file parsing) and
the two Register Context classes uses constants from the system headers
(KERN_SUCCESS, KERN_INVALID_ARGUMENT).
As far as I can tell, these two files don't actually interact with the
darwin kernel -- they are used only in ObjectFileMachO and MacOSX-Kernel
process plugin (even though it has "kernel" in the name, this one
communicates with it via network packets and not syscalls). For the time
being I have created OS-independent definitions of these constants and
made the register context classes use those. Long term, the error
handling in these classes should be probably changed to use more
standard mechanisms such as Status or Error classes.
This is the only change necessary (apart from build system glue) to make
ObjectFileMachO work on other platforms. To demonstrate that, I remove
REQUIRES:darwin from our (only) cross-platform mach-o test.
Reviewers: jasonmolenda, aprantl, clayborg, javed.absar
Subscribers: mgorny, lldb-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D46934
llvm-svn: 332702
LLDB.framework gets loaded into Xcode and other
frameworks, and this is inserting a signal handler into
the process even when lldb isn't used. I have a bunch
of reports of this SignalHandler blowing out the stack,
which renders crash reports for the crash useless.
And in any case libraries really shouldn't be installing
signal handlers.
I only turned this off for APPLE platforms, I'll let
the maintainers of other platforms decide what policy
they want to have w.r.t. this.
llvm-svn: 319598
Summary:
We had a bug where if we had forked (in the ProcessLauncherPosixFork)
while another thread was writing a log message, we would deadlock. This
happened because the fork child inherited the locked log rwmutex, which
would never get unlocked. This meant the child got stuck trying to
disable all log channels.
The bug existed for a while but only started being apparent after
D37930, which started using ThreadLauncher (which uses logging) instead
of std::thread (which does not) for launching TaskPool threads.
The fix is to use pthread_atfork to disable logging in the forked child.
Reviewers: zturner, eugene, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D38938
llvm-svn: 316368
The pthread_atfork trick breaks on android, because
pthread_rwlock_unlock detects that it is not the same thread which
locked the lock. This means that the subsequent lock attempt will still
deadlock (only this time it happens deterministically instead of at
random). Reverting to find a better solution.
This reverts commit r316173.
llvm-svn: 316231
