When printing a std::string_view, print the referenced string as the
summary. Support string_view, u32string_view, u16string_view and
wstring_view, as we do for std::string and friends.
This is based on the existing fomratter for std::string, and just
extracts the data and length members, pushing them through the existing
string formatter.
In testing this, a "FIXME" was corrected for printing of non-ASCII empty
values. Previously, the "u", 'U" etc. prefixes were not printed for
basic_string<> types that were not char. This is trivial to resolve by
printing the prefix before the "".
Differential revision: https://reviews.llvm.org/D112222
Fixes incomplete command names in `apropos` results.
The full command names given by `apropos` have come from command name string
literals given to `CommandObject` constructors. For most commands, this has
been accurate, but some commands have incorrect strings. This results in
`apropos` output that doesn't tell the user the full command name they might
want learn more about. These strings can be fixed.
There's a seperate issue that can't be fixed as easily: plugin commands. With
the way they're implemented, plugin commands have to exclude the root command
from their command name string. To illustrate, the `language objc` subcommand
has to set its command name string to "objc", which results in apropos printing
results as `objc ...` instead of `language objc ...`.
To fix both of these issues, this commit changes `FindCommandsForApropos` to
derive the fully qualified command name using the keys of subcommand maps.
Differential Revision: https://reviews.llvm.org/D116491
Include the complete list of threads of all running processes
in the FreeBSDKernel plugin. This makes it possible to inspect
the states (including partial register dumps from PCB) of all kernel
and userspace threads at the time of crash, or at the time of reading
/dev/mem first.
Differential Revision: https://reviews.llvm.org/D116255
Although we moved to Github Issues. The bug report message refers to
Bugzilla still. This patch tries to update these URLs.
Reviewed By: MaskRay, Quuxplusone, jhenderson, libunwind, libc++
Differential Revision: https://reviews.llvm.org/D116351
There are no duplicates among the include files, and all the
source files are wrapped in architecture ifdefs, so there's no harm
in including all of them, always.
This fixes builds if TARGET_TRIPLE is set to something else than the
build architecture.
This also allows building for multiple architectures at once by
setting CMAKE_OSX_ARCHITECTURES.
Differential Revision: https://reviews.llvm.org/D116625
The current help for `frame variable` is somewhat long. Its length, combined
with the few aliases (`var`, `v`, and `vo`) can make the output of `apropos`
redundant and noisy.
This separates out the details into a separate long help.
Differential Revision: https://reviews.llvm.org/D116708
Until the introduction of the C++ REPL, there was always a single REPL
language. Several places relied on this assumption through
repl_languages.GetSingularLanguage. Now that this is no longer the case,
we need a way to specify a selected/preferred REPL language. This patch
does that with the help of a debugger property, taking inspiration from
how we store the scripting language.
Differential revision: https://reviews.llvm.org/D116697
This reverts commit 640beb38e7.
That commit caused performance degradtion in Quicksilver test QS:sGPU and a functional test failure in (rocPRIM rocprim.device_segmented_radix_sort).
Reverting until we have a better solution to s_cselect_b64 codegen cleanup
Change-Id: Ibf8e397df94001f248fba609f072088a46abae08
Reviewed By: kzhuravl
Differential Revision: https://reviews.llvm.org/D115960
Change-Id: Id169459ce4dfffa857d5645a0af50b0063ce1105
D116372, while fixing one kind of a race, ended up creating a new one.
The new issue could occur when one inferior thread exits while another
thread initiates termination of the entire process (exit_group(2)).
With some bad luck, we could start processing the exit notification
(PTRACE_EVENT_EXIT) only to have the become unresponsive (ESRCH) in the
middle of the MonitorCallback function. This function would then delete
the thread from our list even though it wasn't completely dead (it stays
zombified until we read the WIFEXITED event). The linux kernel will not
deliver the exited event for the entire process until we process
individual thread exits.
In a pre-D116372 world, this wouldn't be a problem because we would read
this event (even though we would not know what to do with it) with
waitpid(-1). Now, when we issue invididual waitpids, this event will
never be picked up, and we end up hanging.
The fix for this is actually quite simple -- don't delete the thread in
this situation. The thread will be deleted when the WIFEXITED event
comes.
This situation was kind of already tested by
TestCreateDuringInstructionStep (which is how I found this problem), but
it was mostly accidental, so I am also creating a dedicated test which
reproduces this situation.
This allows access type be printed when running `lldb-test -dump-ast` and
`lldb-test -dump-clang-ast`.
Differential Revision: https://reviews.llvm.org/D115062
Unlike the rest of our SB objects, SBEvent and SBCommandReturnObject
have the ability to hold non-owning pointers to their non-SB
counterparts. This makes it hard to ensure the SB objects do not become
dangling once their backing object goes away.
While we could make these two objects behave like others, that would
require plubming even more shared pointers through our internal code
(Event objects are mostly prepared for it, CommandReturnObject are not).
Doing so seems unnecessarily disruptive, given that (unlike for some of
the other objects) I don't see any good reason why would someone want to
hold onto these objects after the function terminates.
For that reason, this patch implements a different approach -- the SB
objects will still hold non-owning pointers, but they will be reset to
the empty/default state as soon as the function terminates. This python
code will not crash if the user decides to store these objects -- but
the objects themselves will be useless/empty.
Differential Revision: https://reviews.llvm.org/D116162
Implementation is based on the "expected type" as used for
designated-initializers in braced init lists. This means it can deduce the type
in some cases where it's not written:
void foo(Widget);
foo({ /*help here*/ });
Only basic constructor calls are in scope of this patch, excluded are:
- aggregate initialization (no help is offered for aggregates)
- initializer_list initialization (no help is offered for these constructors)
Fixes https://github.com/clangd/clangd/issues/306
Differential Revision: https://reviews.llvm.org/D116317
Both serve the same purpose (finding shared libraries) and allow one to
launch a dynamically linked executable by just specifying the platform
sysroot.
The lldb-server code is currently set up in a way that each
NativeProcess instance does its own waitpid handling. This works fine
for BSDs, where the code can do a waitpid(process_id), and get
information for all threads in that process.
The situation is trickier on linux, because waitpid(pid) will only
return information for the main thread of the process (one whose tid ==
pid). For this reason the linux code does a waitpid(-1), to get
information for all threads. This was fine while we were supporting just
a single process, but becomes a problem when we have multiple processes
as they end up stealing each others events.
There are two possible solutions to this problem:
- call waitpid(-1) centrally, and then dispatch the events to the
appropriate process
- have each process call waitpid(tid) for all the threads it manages
This patch implements the second approach. Besides fitting better into
the existing design, it also has the added benefit of ensuring
predictable ordering for thread/process creation events (which come in
pairs -- one for the parent and one for the child). The first approach
OTOH, would make this ordering even more complicated since we would
have to keep the half-threads hanging in mid-air until we find the
process we should attach them to.
The downside to this approach is an increased number of syscalls (one
waitpid for each thread), but I think we're pretty far from optimizing
things like this, and so the cleanliness of the design is worth it.
The included test reproduces the circumstances which should demonstrate
the bug (which manifests as a hung test), but I have not been able to
get it to fail. The only place I've seen this failure modes are very
rare hangs in the thread sanitizer tests (tsan forks an addr2line
process to produce its error messages).
Differential Revision: https://reviews.llvm.org/D116372
This is a re-submission of 24d2405588
without the hunks in HostNativeThreadBase.{h,cpp}, which break builds
on Windows.
Identified with modernize-use-nullptr.
This reverts commit 913457acf0.
It again broke builds on Windows:
lldb/source/Host/common/HostNativeThreadBase.cpp(37,14): error:
assigning to 'lldb::thread_result_t' (aka 'unsigned int') from
incompatible type 'std::nullptr_t'
This is a re-submission of 24d2405588
without the hunk in HostNativeThreadBase.h, which breaks builds on
Windows.
Identified with modernize-use-nullptr.
This reverts commit 24d2405588.
Breaks building on Windows:
../../lldb/include\lldb/Host/HostNativeThreadBase.h(49,36): error:
cannot initialize a member subobject of type 'lldb::thread_result_t'
(aka 'unsigned int') with an rvalue of type 'std::nullptr_t'
lldb::thread_result_t m_result = nullptr;
^~~~~~~
1 error generated.
This small patch adds two useful improvements:
- allows one to specify the emulator path as a bare filename, and have
it be looked up in the PATH
- allows one to leave the path empty and have the filename be derived
from the architecture.
It was being used only in some very old tests (which pass even without
it) and its implementation is highly questionable.
These days we have different mechanisms for requesting a build with a
particular kind of c++ library (USE_LIB(STD)CPP in the makefile).
The MonitorCallback function was assuming that the "exited" argument is
set whenever a thread exits, but the caller was only setting that flag
for the main thread.
This patch deletes the argument altogether, and lets MonitorCallback
compute what it needs itself.
This is almost NFC, since previously we would end up in the
"GetSignalInfo failed for unknown reasons" branch, which was doing the
same thing -- forgetting about the thread.
Remove the Mangled::operator! and Mangled::operator void* where the
comments in header and implementation files disagree and replace them
with operator bool.
This fix PR52702 as https://reviews.llvm.org/D106837 used the buggy
Mangled::operator! in Symbol::SynthesizeNameIfNeeded. For example,
consider the symbol "puts" in a hello world C program:
// Inside Symbol::SynthesizeNameIfNeeded
(lldb) p m_mangled
(lldb_private::Mangled) $0 = (m_mangled = None, m_demangled = "puts")
(lldb) p !m_mangled
(bool) $1 = true # should be false!!
This leads to Symbol::SynthesizeNameIfNeeded overwriting m_demangled
part of Mangled (in this case "puts").
In conclusion, this patch turns
callq 0x401030 ; symbol stub for: ___lldb_unnamed_symbol36
back into
callq 0x401030 ; symbol stub for: puts .
Differential Revision: https://reviews.llvm.org/D116217
Now that we are caching the dwarf index as well, we will always have
more than one cache file (when not using accelerator tables). I have
adjusted the test to check for the presence of one _symtab_ index.
Multithreaded applications using fork(2) need to be extra careful about
what they do in the fork child. Without any special precautions (which
only really work if you can fully control all threads) they can only
safely call async-signal-safe functions. This is because the forked
child will contain snapshot of the parents memory at a random moment in
the execution of all of the non-forking threads (this is where the
similarity with signals comes in).
For example, the other threads could have been holding locks that can
now never be released in the child process and any attempt to obtain
them would block. This is what sometimes happen when using tcmalloc --
our fork child ends up hanging in the memory allocation routine. It is
also what happened with our logging code, which is why we added a
pthread_atfork hackaround.
This patch implements a proper fix to the problem, by which is to make
the child code async-signal-safe. The ProcessLaunchInfo structure is
transformed into a simpler ForkLaunchInfo representation, one which can
be read without allocating memory and invoking complex library
functions.
Strictly speaking this implementation is not async-signal-safe, as it
still invokes library functions outside of the posix-blessed set of
entry points. Strictly adhering to the spec would mean reimplementing a
lot of the functionality in pure C, so instead I rely on the fact that
any reasonable implementation of some functions (e.g.,
basic_string::c_str()) will not start allocating memory or doing other
unsafe things.
The new child code does not call into our logging infrastructure, which
enables us to remove the pthread_atfork call from there.
Differential Revision: https://reviews.llvm.org/D116165
When we switched options over to use the Options.td file, a bug was introduced that caused the "-g" option for "settings set" to require a filename arguemnt. This patch fixes this issue and adds a test so this doesn't regress.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D116012
This patch add the ability to cache the manual DWARF indexing results to disk for faster subsequent debug sessions. Manual DWARF indexing is time consuming and causes all DWARF to be fully parsed and indexed each time you debug a binary that doesn't have an acceptable accelerator table. Acceptable accelerator tables include .debug_names in DWARF5 or Apple accelerator tables.
This patch breaks up testing by testing all of the encoding and decoding of required C++ objects in a gtest unit test, and then has a test to verify the debug info cache is generated correctly.
This patch also adds the ability to track when a symbol table or DWARF index is loaded or saved to the cache in the "statistics dump" command. This is essential to know in statistics as it can help explain why a debug session was slower or faster than expected.
Reviewed By: labath, wallace
Differential Revision: https://reviews.llvm.org/D115951
Support three new keys in the qProcessInfo response from the remote
gdb stub to handle the case of attaching to a core running some type
of standalone/firmware code and the stub knows the UUID and load
address-or-slide for the binary. There will be no proper DynamicLoader
plugin in this scenario, but we can try to locate and load the binary
into lldb at the correct offset.
Differential Revision: https://reviews.llvm.org/D116211
rdar://75191077
Introduce initial support for using libkvm on FreeBSD. The library
can be used as an alternate implementation for processing kernel
coredumps but it can also be used to access live kernel memory through
specifying "/dev/mem" as the core file, i.e.:
lldb --core /dev/mem /boot/kernel/kernel
Differential Revision: https://reviews.llvm.org/D116005
This finishes the GetSupportedArchitectureAtIndex migration. There are
opportunities to simplify this even further, but I am going to leave
that to the platform owners.
Differential Revision: https://reviews.llvm.org/D116028
Version 2 of 'main bin spec' LC_NOTE allows for the specification
of a slide of where the binary is loaded in the corefile virtual
address space. It also adds a (currently unused) platform field
for the main binary.
Some corefile creators will only have a UUID and an offset to be
applied to the binary.
Changed TestFirmwareCorefiles.py to test this new form of
'main bin spec' with a slide, and also to run on both x86_64
and arm64 macOS systems.
Differential Revision: https://reviews.llvm.org/D116094
rdar://85938455
Extracted from D99484. My new plan is to start from the outside and work
inward.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D115570
This reverts commit cc56c66f27.
Fixed a bad assertion, the target of a UsingShadowDecl must not have
*local* qualifiers, but it can be a typedef whose underlying type is qualified.
Currently there's no way to find the UsingDecl that a typeloc found its
underlying type through. Compare to DeclRefExpr::getFoundDecl().
Design decisions:
- a sugar type, as there are many contexts this type of use may appear in
- UsingType is a leaf like TypedefType, the underlying type has no TypeLoc
- not unified with UnresolvedUsingType: a single name is appealing,
but being sometimes-sugar is often fiddly.
- not unified with TypedefType: the UsingShadowDecl is not a TypedefNameDecl or
even a TypeDecl, and users think of these differently.
- does not cover other rarer aliases like objc @compatibility_alias,
in order to be have a concrete API that's easy to understand.
- implicitly desugared by the hasDeclaration ASTMatcher, to avoid
breaking existing patterns and following the precedent of ElaboratedType.
Scope:
- This does not cover types associated with template names introduced by
using declarations. A future patch should introduce a sugar TemplateName
variant for this. (CTAD deduced types fall under this)
- There are enough AST matchers to fix the in-tree clang-tidy tests and
probably any other matchers, though more may be useful later.
Caveats:
- This changes a fairly common pattern in the AST people may depend on matching.
Previously, typeLoc(loc(recordType())) matched whether a struct was
referred to by its original scope or introduced via using-decl.
Now, the using-decl case is not matched, and needs a separate matcher.
This is similar to the case of typedefs but nevertheless both adds
complexity and breaks existing code.
Differential Revision: https://reviews.llvm.org/D114251
This starts to fix the other half of the lifetime problems in this code
-- dangling references. SB objects created on the stack will go away
when the function returns, which is a problem if the python code they
were meant for stashes a reference to them somewhere. Most of the time
this goes by unnoticed, as the code rarely has a reason to store these,
but in case it does, we shouldn't respond by crashing.
This patch fixes the management for a couple of SB objects (Debugger,
Frame, Thread). The SB objects are now created on the heap, and
their ownership is immediately passed on to SWIG, which will ensure they
are destroyed when the last python reference goes away. I will handle
the other objects in separate patches.
I include one test which demonstrates the lifetime issue for SBDebugger.
Strictly speaking, one should create a test case for each of these
objects and each of the contexts they are being used. That would require
figuring out how to persist (and later access) each of these objects.
Some of those may involve a lot of hoop-jumping (we can run python code
from within a frame-format string). I don't think that is
necessary/worth it since the new wrapper functions make it very hard to
get this wrong.
Differential Revision: https://reviews.llvm.org/D115925
The test was attempting to make a universal x86_64/arm64 binary, but some older bots don't have a macOS SDK that can handle this. Switching over to using a yaml file instead should solve the problem.
This setting is for variables we want to pass to the emulator only --
then will be automatically removed from the target environment by our
environment diffing code. This variable can be used to pass various
QEMU_*** variables (although most of these can be passed through
emulator-args as well), as well as any other variables that can affect
the operation of the emulator (e.g. LD_LIBRARY_PATH).
They were being applied too narrowly (they didn't cover signed char *,
for instance), and too broadly (they covered SomeTemplate<char[6]>) at
the same time.
Differential Revision: https://reviews.llvm.org/D112709
This is an updated version of the https://reviews.llvm.org/D113789 patch with the following changes:
- We no longer modify modification times of the cache files
- Use LLVM caching and cache pruning instead of making a new cache mechanism (See DataFileCache.h/.cpp)
- Add signature to start of each file since we are not using modification times so we can tell when caches are stale and remove and re-create the cache file as files are changed
- Add settings to control the cache size, disk percentage and expiration in days to keep cache size under control
This patch enables symbol tables to be cached in the LLDB index cache directory. All cache files are in a single directory and the files use unique names to ensure that files from the same path will re-use the same file as files get modified. This means as files change, their cache files will be deleted and updated. The modification time of each of the cache files is not modified so that access based pruning of the cache can be implemented.
The symbol table cache files start with a signature that uniquely identifies a file on disk and contains one or more of the following items:
- object file UUID if available
- object file mod time if available
- object name for BSD archive .o files that are in .a files if available
If none of these signature items are available, then the file will not be cached. This keeps temporary object files from expressions from being cached.
When the cache files are loaded on subsequent debug sessions, the signature is compare and if the file has been modified (uuid changes, mod time changes, or object file mod time changes) then the cache file is deleted and re-created.
Module caching must be enabled by the user before this can be used:
symbols.enable-lldb-index-cache (boolean) = false
(lldb) settings set symbols.enable-lldb-index-cache true
There is also a setting that allows the user to specify a module cache directory that defaults to a directory that defaults to being next to the symbols.clang-modules-cache-path directory in a temp directory:
(lldb) settings show symbols.lldb-index-cache-path
/var/folders/9p/472sr0c55l9b20x2zg36b91h0000gn/C/lldb/IndexCache
If this setting is enabled, the finalized symbol tables will be serialized and saved to disc so they can be quickly loaded next time you debug.
Each module can cache one or more files in the index cache directory. The cache file names must be unique to a file on disk and its architecture and object name for .o files in BSD archives. This allows universal mach-o files to support caching multuple architectures in the same module cache directory. Making the file based on the this info allows this cache file to be deleted and replaced when the file gets updated on disk. This keeps the cache from growing over time during the compile/edit/debug cycle and prevents out of space issues.
If the cache is enabled, the symbol table will be loaded from the cache the next time you debug if the module has not changed.
The cache also has settings to control the size of the cache on disk. Each time LLDB starts up with the index cache enable, the cache will be pruned to ensure it stays within the user defined settings:
(lldb) settings set symbols.lldb-index-cache-expiration-days <days>
A value of zero will disable cache files from expiring when the cache is pruned. The default value is 7 currently.
(lldb) settings set symbols.lldb-index-cache-max-byte-size <size>
A value of zero will disable pruning based on a total byte size. The default value is zero currently.
(lldb) settings set symbols.lldb-index-cache-max-percent <percentage-of-disk-space>
A value of 100 will allow the disc to be filled to the max, a value of zero will disable percentage pruning. The default value is zero.
Reviewed By: labath, wallace
Differential Revision: https://reviews.llvm.org/D115324
Pass QUIET to find_package() in order to quiet the warning about missing
FindFBSDVMCore.cmake. FBSDVMCore always provides native CMake config
files, therefore providing a fallback module serves no purpose.
Differential Revision: https://reviews.llvm.org/D115882
I've found my recent ventures into the swig land painful because
of the strange way they are formatted. This patch attempts to alleviate
future headaches by formatting these files into something resembling the
normal llvm style.
Unfortunately, completely formatting these files automatically does not
work because clang format gets confused by swigs % syntax, so I have
employed a hybrid approach where I formatted blocks of c++ code with
clang-format and then manually massaged the code until it looked
reasonable (and compiled).
I don't expect these files to remain perfectly formatted (although, if
one's editor is configured to configure the current line/block on
request, one can get pretty good results by using it judiciously), but
at least it will prevent the (mangled form of the) old lldb style being
proliferated endlessly.
Differential Revision: https://reviews.llvm.org/D115736
Introduce a FreeBSDKernel plugin that provides the ability to read
FreeBSD kernel core dumps. The plugin utilizes libfbsdvmcore to provide
support for both "full memory dump" and minidump formats across variety
of architectures supported by FreeBSD. It provides the ability to read
kernel memory, as well as the crashed thread status with registers
on arm64, i386 and x86_64.
Differential Revision: https://reviews.llvm.org/D114911
The pdb lldb tests do not work correctly with both the VS2019 and VS2017 toolsets at the moment. This change updates several of the tests to work with both toolsets. Unfortunately, this makes the tests suboptimal for both toolsets, but we can update them to be better for VS2019 once we officially drop VS2017. This change is meant to bridge the gap until the update happens, so that the buildbots can work with either toolset.
Differential Revision: https://reviews.llvm.org/D115482
Currently, we'll try to instantiate a ClangREPL for every known
language. The plugin manager already knows what languages it supports,
so rely on that to only instantiate a REPL when we know the requested
language is supported.
rdar://86439474
Differential revision: https://reviews.llvm.org/D115698
Introduce a FreeBSDKernel plugin that provides the ability to read
FreeBSD kernel core dumps. The plugin utilizes libfbsdvmcore to provide
support for both "full memory dump" and minidump formats across variety
of architectures supported by FreeBSD. It provides the ability to read
kernel memory, as well as the crashed thread status with registers
on arm64, i386 and x86_64.
Differential Revision: https://reviews.llvm.org/D114911
Add lldb support for a Mach-O "load binary" LC_NOTE which provides
a UUID, load address/slide, and possibly a name of a binary that
should be loaded when examining the core.
struct load_binary
{
uint32_t version; // currently 1
uuid_t uuid; // all zeroes if uuid not specified
uint64_t load_address; // virtual address where the macho is loaded, UINT64_MAX if unavail
uint64_t slide; // slide to be applied to file address to get load address, 0 if unavail
char name_cstring[]; // must be nul-byte terminated c-string, '\0' alone if name unavail
} __attribute__((packed));
Differential Revision: https://reviews.llvm.org/D115494
rdar://85069250
StructuredDataImpl ownership semantics is unclear at best. Various
structures were holding a non-owning pointer to it, with a comment that
the object is owned somewhere else. From what I was able to gather that
"somewhere else" was the SBStructuredData object, but I am not sure that
all created object eventually made its way there. (It wouldn't matter
even if they did, as we are leaking most of our SBStructuredData
objects.)
Since StructuredDataImpl is just a collection of two (shared) pointers,
there's really no point in elaborate lifetime management, so this patch
replaces all StructuredDataImpl pointers with actual objects or
unique_ptrs to it. This makes it much easier to resolve SBStructuredData
leaks in a follow-up patch.
Differential Revision: https://reviews.llvm.org/D114791
This commit should fix a heap-use-after-free bug that was caught by the
sanitizer bot.
The issue is that we were reading memory from a second target into a
`SBData` object in Python, that was passed to lldb's internal
`ScriptedProcess::DoReadMemory` C++ method.
The ScriptedPythonInterface then extracts the underlying `DataExtractor`
from the `SBData` object, and is used to read the memory with the
appropriate address size and byte order.
Unfortunately, it seems that even though the DataExtractor object was
still valid, it pointed to invalid, possibly garbage-collected memory
from Python.
To mitigate this, the patch uses `SBData::SetDataWithOwnership` to copy
the pointed buffer to lldb's heap memory which prevents the
use-after-free error.
rdar://84511405
Differential Revision: https://reviews.llvm.org/D115654
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces a new method to SBData: SetDataWithOwnership.
Instead of referencing the pointer to the data, this method copies the
data buffer into lldb's heap memory.
This can prevent having the underlying DataExtractor object point to
freed/garbage-collected memory.
Differential Revision: https://reviews.llvm.org/D115652
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Just defensive CMake-ing. I pulled this from D115544 and D99484 which
are blocked on some lldb CI failures I don't yet understand. Hoping to land
something smaller in the meantime.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D115566
This reverts commit 492de35df4.
I tried to apply John's changes in 8d897ec915 that were expected to
fix his patch but that didn't work unfortunately.
Reverting this again to fix the macOS bots and leave him more time to
investigate the issue.
This reverts commit 797b50d4be.
See the original D99484. @mib who noticed the original problem could not longer
reproduce it, after I tried and also failed. We are threfore hoping it went
away on its own!
Reviewed By: mib
Differential Revision: https://reviews.llvm.org/D115544
The change to ArchSpec::SetArchitecture that was setting the
ObjectFile of a mach-o binary to llvm::Triple::MachO. It's not
necessary for my patch, and it changes the output of image list -t
causing TestUniversal.py to fail on x86_64 systems. The bots
turned up the failure, I was developing and testing this on
an Apple Silicon mac.
With arm64e ARMv8.3 pointer authentication, lldb needs to know how
many bits are used for addressing and how many are used for pointer
auth signing. This should be determined dynamically from the inferior
system / corefile, but there are some workflows where it still isn't
recorded and we fall back on a default value that is correct on some
Darwin environments.
This patch also explicitly sets the vendor of mach-o binaries to
Apple, so we select an Apple ABI instead of a random other ABI.
It adds a function pointer formatter for systems where pointer
authentication is in use, and we can strip the ptrauth bits off
of the function pointer address and get a different value that
points to an actual symbol.
Differential Revision: https://reviews.llvm.org/D115431
rdar://84644661
This is a post-review update for D115313, to rephrase source display
warning messages for artificial locations, making them more
understandable for the end-user.
Differential Revision: https://reviews.llvm.org/D115461
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
It can happen that a line entry reports that some source code is located
at line 0. In DWARF, line 0 is a special location which indicates that
code has no 1-1 mapping with source.
When stopping in one of those artificial locations, lldb doesn't know which
line to display and shows the beginning of the file instead.
This patch mitigates this behaviour by checking if the current symbol context
of the line entry has a matching function, in which case, it slides the
source listing to the start of that function.
This patch also shows the user a warning explaining why lldb couldn't
show sources at that location.
rdar://83118425
Differential Revision: https://reviews.llvm.org/D115313
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
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 can be unsigned long or unsigned long long depending on where it's
compiled. Use the ugly portable way.
PlatformWindows.cpp:397:63: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long')
The test for this functionality was failing on the darwin bot, because
the entries came out in opposite order. While this does not impact
functionality, and the algorithm that produces it is technically
deterministic (the nondeterminism comes from the contents of the host
environment), it seems like it would be more user-friendly if the
entries came out in a more predictible order.
Therefore I am adding the sort call to the actual code instead of
relaxing test expectations.
Test is using "next" commands to make progress in the process. D115137
added an additional statement to the program, without adding a command
to step over it. This only seemed to matter for the libc++ flavour of
the test, possibly because libstdc++ list is "empty" in its
uninitialized state.
Since moving with step commands is a treacherous, this patch adds a
run-to-breakpoint command to the test. It only does this for the
affected step, but one may consider doing it elsewhere too.
Qemu normally forwards its (host) environment variables to the emulated
process. While this works fine for most variables, there are some (few, but
fairly important) variables where this is not possible. LD_LIBRARY_PATH
is the probably the most important of those -- we don't want the library
search path for the emulated libraries to interfere with the libraries
that the emulator itself needs.
For this reason, qemu provides a mechanism (QEMU_SET_ENV,
QEMU_UNSET_ENV) to set variables only for the emulated process. This
patch makes use of that functionality to pass any user-provided
variables to the emulated process. Since we're piggy-backing on the
normal lldb environment-handling mechanism, all the usual mechanism to
provide environment (target.env-vars setting, SBLaunchInfo, etc.) work
out-of-the-box, and the only thing we need to do is to properly
construct the qemu environment variables.
This patch also adds a new setting -- target-env-vars, which represents
environment variables which are added (on top of the host environment)
to the default launch environments of all (qemu) targets. The reason for
its existence is to enable the configuration (e.g., from a startup
script) of the default launch environment, before any target is created.
The idea is that this would contain the variables (like the
aforementioned LD_LIBRARY_PATH) common to all targets being debugged on
the given system. The user is, of course, free to customize the
environment for a particular target in the usual manner.
The reason I do not want to use/recommend the "global" version of the
target.env-vars setting for this purpose is that the setting would apply
to all targets, whereas the settings (their values) I have mentioned
would be specific to the given platform.
Differential Revision: https://reviews.llvm.org/D115246
Also add tests to check that we print the warning in the right
circumstances.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D114877
This is a split of D113724. Calling `TypeSystemClang::AddMethodToCXXRecordType`
to create function decls for class methods.
Differential Revision: https://reviews.llvm.org/D113930
DataEncoder was previously made to modify data within an existing buffer. As the code progressed, new clients started using DataEncoder to create binary data. In these cases the use of this class was possibly, but only if you knew exactly how large your buffer would be ahead of time. This patchs adds the ability for DataEncoder to own a buffer that can be dynamically resized as data is appended to the buffer.
Change in this patch:
- Allow a DataEncoder object to be created that owns a DataBufferHeap object that can dynamically grow as data is appended
- Add new methods that start with "Append" to append data to the buffer and grow it as needed
- Adds full testing of the API to assure modifications don't regress any functionality
- Has two constructors: one that uses caller owned data and one that creates an object with object owned data
- "Append" methods only work if the object owns it own data
- Removes the ability to specify a shared memory buffer as no one was using this functionality. This allows us to switch to a case where the object owns its own data in a DataBufferHeap that can be resized as data is added
"Put" methods work on both caller and object owned data.
"Append" methods work on only object owned data where we can grow the buffer. These methods will return false if called on a DataEncoder object that has caller owned data.
The main reason for these modifications is to be able to use the DateEncoder objects instead of llvm::gsym::FileWriter in https://reviews.llvm.org/D113789. This patch wants to add the ability to create symbol table caching to LLDB and the code needs to build binary caches and save them to disk.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D115073
The test was flaky because it was trying to read from the (redirected)
stdout file before the data was been flushed to it. This would not be a
problem for a "normal" debug session, but since here the emulator and
the target binary coexist in the same process (and this is true both for
real qemu and our fake implementation), there
is a window of time between the stub returning an exit packet (which is
the event that the test is waiting for) and the process really exiting
(which is when the normal flushing happens).
This patch adds an explicit flush to work around this. Theoretically,
it's possible that real code could run into this issue as well, but such
a use case is not very likely. If we wanted to fix this for real, we
could add some code which waits for the host process to terminate (in
addition to receiving the termination packet), but this is somewhat
complicated by the fact that this code lives in the gdb-remote process
plugin.
This setting allows the user to pass additional arguments to the qemu instance.
While we may want to introduce dedicated settings for the most common qemu
arguments (-cpu, for one), having this setting allows us to avoid creating a
setting for every possible argument.
Differential Revision: https://reviews.llvm.org/D115151
This patch should fix a Windows test failure for the
InvalidScriptedThread test:
https://lab.llvm.org/buildbot/#/builders/83/builds/12571
This refactors the test to stop using python `tempfile` since it's not
supported on Windows and creates a logfile at runtime in the test folder.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds support for arm64(e) targets to ScriptedProcess, by
providing the `DynamicRegisterInfo` to the base `lldb.ScriptedThread` class.
This allows create and debugging ScriptedProcess on Apple Silicon
hardware as well as Apple mobile devices.
It also replace the C++ asserts on `ScriptedThread::GetDynamicRegisterInfo`
by some error logging, re-enables `TestScriptedProcess` for arm64
Darwin platforms and adds a new invalid Scripted Thread test.
rdar://85892451
Differential Revision: https://reviews.llvm.org/D114923
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
While profiling lldb (from swift/llvm-project), these timers were noticed to be short lived and high firing, and so they add noise more than value.
The data points I recorded are:
`FindTypes_Impl`: 49,646 calls, 812ns avg, 40.33ms total
`AppendSymbolIndexesWithName`: 36,229 calls, 913ns avg, 33.09ms total
`FindAllSymbolsWithNameAndType`: 36,229 calls, 1.93µs avg, 70.05ms total
`FindSymbolsWithNameAndType`: 23,263 calls, 3.09µs avg, 71.88ms total
Differential Revision: https://reviews.llvm.org/D115182
This adds extra tests for libstdcpp and libcxx list and forward_list formatters to check whether formatter behaves correctly when applied on pointer and reference values.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D115137
This adds the formatters for libstdcpp's deque as a python
implementation. It adds comprehensive tests for the two different
storage strategies deque uses. Besides that, this fixes a couple of bugs
in the libcxx implementation. Finally, both implementation run against
the same tests.
This is a minor improvement on top of Danil Stefaniuc's formatter.
Lldb uses a pty to read/write to the standard input and output of the
debugged process. For host processes this would be automatically set up
by Target::FinalizeFileActions. The Qemu platform is in a unique
position of not really being a host platform, but not being remote
either. It reports IsHost() = false, but it is sufficiently host-like
that we can use the usual pty mechanism.
This patch adds the necessary glue code to enable pty redirection. It
includes a small refactor of Target::FinalizeFileActions and
ProcessLaunchInfo::SetUpPtyRedirection to reduce the amount of
boilerplate that would need to be copied.
I will note that qemu is not able to separate output from the emulated
program from the output of the emulator itself, so the two will arrive
intertwined. Normally this should not be a problem since qemu should not
produce any output during regular operation, but some output can slip
through in case of errors. This situation should be pretty obvious (to a
human), and it is the best we can do anyway.
For testing purposes, and inspired by lldb-server tests, I have extended
the mock emulator with the ability "program" the behavior of the
"emulated" program via command-line arguments.
Differential Revision: https://reviews.llvm.org/D114796
Recognize FreeBSD vmcores (kernel core dumps) through OS ABI = 0xFF
+ ELF version = 0, and do not process them via the elf-core plugin.
While these files use ELF as a container format, they contain raw memory
dump rather than proper VM segments and therefore are not usable
to the elf-core plugin.
Differential Revision: https://reviews.llvm.org/D114967
This patch fixes:
lldb/source/Plugins/Platform/Windows/PlatformWindows.cpp:386:13:
error: comparison between NULL and non-pointer ('lldb::addr_t' (aka
'unsigned long') and NULL) [-Werror,-Wnull-arithmetic]
This implements `DoLoadImage` and `UnloadImage` in the Windows platform
plugin modelled after the POSIX platform plugin. This was previously
unimplemented and resulted in a difficult to decipher error without any
logging.
This implementation is intended to support enables the use of LLDB's
Swift REPL on Windows.
Paths which are added to the library search path are persistent and
applied to all subsequent loads. This can be adjusted in the future by
storing all the cookies and restoring the path prior to returning from
the helper. However, the dynamic path count makes this a bit more
challenging.
Reviewed By: @JDevlieghere
Differential Revision: https://reviews.llvm.org/D77287
minidebuginfo-set-and-hit-breakpoint.test is failing on Arm/Linux most
probably due to an ill formed binary after removal of certain sections
from executable. I am marking it as XFAIL for further investigation.
Some pythons are configured to set platlib somewhere outside of their
sys.prefix. It's important that we at least use some reasonable
default for LLDB_PYTHON_RELATIVE_PATH even in that case, because
even if the user overrides it on the cmake invocation, cmake will
still be called without the override in order to build tablegen.
Reviewed By: JDevlieghere, clayborg
Differential Revision: https://reviews.llvm.org/D114973
When debugging a Simulator process on macOS (e.g. the iPhone simulator),
the process will have both a dyld, and a dyld_sim present. The dyld_sim
is an iOS Simulator binary. The dyld is a macOS binary. Both are
MH_DYLINKER filetypes. lldb needs to identify & set a breakpoint in
dyld, so it has to distinguish between these two.
Previously lldb was checking if the inferior target was x86 (indicating
macOS) and the OS of the MH_DYLINKER binary was iOS/watchOS/etc -- if
so, then this is dyld_sim and we should ignore it. Now with arm64
macOS systems, this check was invalid, and we would set our breakpoint
for new binaries being loaded in dyld_sim, causing binary loading to
be missed by lldb.
This patch uses the Target's ArchSpec triple environment, to see if
this process is a simulator process. If this is a Simulator process,
then we only recognize a MH_DYLINKER binary with OS type macOS as
being dyld.
This patch also removes some code that handled pre-2016 era debugservers
which didn't give us the OS type for each binary. This was only being
used on macOS, where we don't need to handle the presence of very old
debugservers.
Differential Revision: https://reviews.llvm.org/D115001
rdar://85907839
Only lldb-arm-ubuntu is failing after https://reviews.llvm.org/D114288 and there isn't enough input context to see why this is failing. It works on x86_64 linux just fine.
These tests work fine with VS2017, but become more flaky with VS2019 and the buildbot is about to get upgraded.
Differential Revision: https://reviews.llvm.org/D114907
Split TestCxxChar8_t into two parts: one that check reading variables
without a process and another part with. This allows us to skip the
former on Apple Silicon, where lack of support for chained fix-ups
causes the test to fail.
Differential revision: https://reviews.llvm.org/D114819
Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this change, the "Symbtab *ObjectFile::GetSymtab()" is no longer virtual and will end up calling a new "void ObjectFile::ParseSymtab(Symtab &symtab)" pure virtual function to actually do the parsing. This helps centralize the code for parsing the symbol table and allows the ObjectFile base class to do all of the common work, like taking the necessary locks and creating the symbol table object itself. Plug-ins now just need to parse when they are asked to parse as the ParseSymtab function will only get called once.
This is a retry of the original patch https://reviews.llvm.org/D113965 which was reverted. There was a deadlock in the Manual DWARF indexing code during symbol preloading where the module was asked on the main thread to preload its symbols, and this would in turn cause the DWARF manual indexing to use a thread pool to index all of the compile units, and if there were relocations on the debug information sections, these threads could ask the ObjectFile to load section contents, which could cause a call to ObjectFileELF::RelocateSection() which would ask for the symbol table from the module and it would deadlock. We can't lock the module in ObjectFile::GetSymtab(), so the solution I am using is to use a llvm::once_flag to create the symbol table object once and then lock the Symtab object. Since all APIs on the symbol table use this lock, this will prevent anyone from using the symbol table before it is parsed and finalized and will avoid the deadlock I mentioned. ObjectFileELF::GetSymtab() was never locking the module lock before and would put off creating the symbol table until somewhere inside ObjectFileELF::GetSymtab(). Now we create it one time inside of the ObjectFile::GetSymtab() and immediately lock it which should be safe enough. This avoids the deadlocks and still provides safety.
Differential Revision: https://reviews.llvm.org/D114288
727bd89b60 broke the UBSan decorator. The decorator compiles a custom
source code snippet that exposes UB and verifies the presence of a UBSan
symbol in the generated binary. The aforementioned commit broke both by
compiling a snippet without UB and discarding the result.
Make sure to add the PrivateFrameworks directory to the frameworks path
when using an internal SDK. This is necessary for the "on-device" test
suite.
rdar://84519268
Differential revision: https://reviews.llvm.org/D114742
This adds a new platform class, whose job is to enable running
(debugging) executables under qemu.
(For general information about qemu, I recommend reading the RFC thread
on lldb-dev
<https://lists.llvm.org/pipermail/lldb-dev/2021-October/017106.html>.)
This initial patch implements the necessary boilerplate as well as the
minimal amount of functionality needed to actually be able to do
something useful (which, in this case means debugging a fully statically
linked executable).
The knobs necessary to emulate dynamically linked programs, as well as
to control other aspects of qemu operation (the emulated cpu, for
instance) will be added in subsequent patches. Same goes for the ability
to automatically bind to the executables of the emulated architecture.
Currently only two settings are available:
- architecture: the architecture that we should emulate
- emulator-path: the path to the emulator
Even though this patch is relatively small, it doesn't lack subtleties
that are worth calling out explicitly:
- named sockets: qemu supports tcp and unix socket connections, both of
them in the "forward connect" mode (qemu listening, lldb connecting).
Forward TCP connections are impossible to realise in a race-free way.
This is the reason why I chose unix sockets as they have larger, more
structured names, which can guarantee that there are no collisions
between concurrent connection attempts.
- the above means that this code will not work on windows. I don't think
that's an issue since user mode qemu does not support windows anyway.
- Right now, I am leaving the code enabled for windows, but maybe it
would be better to disable it (otoh, disabling it means windows
developers can't check they don't break it)
- qemu-user also does not support macOS, so one could contemplate
disabling it there too. However, macOS does support named sockets, so
one can even run the (mock) qemu tests there, and I think it'd be a
shame to lose that.
Differential Revision: https://reviews.llvm.org/D114509
The LLDBSWIGPython functions had (at least) two problems:
- There wasn't a single source of truth (a header file) for the
prototypes of these functions. This meant that subtle differences
in copies of function declarations could go by undetected. And
not-so-subtle differences would result in strange runtime failures.
- All of the declarations had to have an extern "C" interface, because
the function definitions were being placed inside and extert "C" block
generated by swig.
This patch fixes both problems by moving the function definitions to the
%header block of the swig files. This block is not surrounded by extern
"C", and seems more appropriate anyway, as swig docs say it is meant for
"user-defined support code" (whereas the previous %wrapper code was for
automatically-generated wrappers).
It also puts the declarations into the SWIGPythonBridge header file
(which seems to have been created for this purpose), and ensures it is
included by all code wishing to define or use these functions. This
means that any differences in the declaration become a compiler error
instead of a runtime failure.
Differential Revision: https://reviews.llvm.org/D114369
This reverts commit fac3f20de5.
I found this has broken how we detect the last memory region in
GetMemoryRegions/"memory region" command.
When you're debugging an AArch64 system with pointer authentication,
the ABI plugin will remove the top bit from the end address of the last
user mapped area.
(lldb)
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
ABI plugin removes anything above the 48th bit (48 bit virtual addresses
by default on AArch64, leaving an address of 0.
(lldb)
[0x0000000000000000-0x0000000000400000) ---
You get back a mapping for 0 and get into an infinite loop.
Certain commands like 'memory write', 'register read' etc all use
the OptionGroupFormat options but the help usage text for those
options is not customized to those commands.
One such example is:
(lldb) help memory read
-s <byte-size> ( --size <byte-size> )
The size in bytes to use when displaying with the selected format.
(lldb) help memory write
-s <byte-size> ( --size <byte-size> )
The size in bytes to use when displaying with the selected format.
This patch allows such commands to overwrite the help text for the options
in the OptionGroupFormat group as needed and fixes help text of memory write.
llvm.org/pr49018.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D114448
Currently the 'memory write' command allows specifying the values when
writing the file contents to memory but the values are actually ignored. This
patch fixes that by erroring out when values are specified in such cases.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D114544
On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu.
Patch adds them to libclang, so LLDB jitter has more chances to compile expression.
OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D110827
Although I cannot find any mention of this in the specification, both
gdb and lldb agree on sending an initial + packet after establishing the
connection.
OTOH, gdbserver and lldb-server behavior is subtly different. While
lldb-server *expects* the initial ack, and drops the connection if it is
not received, gdbserver will just ignore a spurious ack at _any_ point
in the connection.
This patch changes lldb's behavior to match that of gdb. An ACK packet
is ignored at any point in the connection (except when expecting an ACK
packet, of course). This is inline with the "be strict in what you
generate, and lenient in what you accept" philosophy, and also enables
us to remove some special cases from the server code. I've extended the
same handling to NAK (-) packets, mainly because I don't see a reason to
treat them differently here.
(The background here is that we had a stub which was sending spurious
+ packets. This bug has since been fixed, but I think this change makes
sense nonetheless.)
Differential Revision: https://reviews.llvm.org/D114520
This code, added in rL197579 (Dec 2013) is supposed to work around what
was presumably a qemu bug, where it would send unsolicited stop-reply
packets after the initial connection.
At present, qemu does not exhibit such behavior. Also, the 10ms delay
introduced by this code is sufficient to mask bugs in other stubs, but
it is not sufficient to *reliably* mask those bugs. This resulted in
flakyness in one of our stubs, which was (incorrectly) sending a +
packet at the start of the connection, resulting in a small-but-annoying
number of dropped connections.
Differential Revision: https://reviews.llvm.org/D114529
Right now if the LLDB is compiled under the windows with static vcruntime library, the -o and -k commands will not work.
The problem is that the LLDB create FILE* in lldb.exe and pass it to liblldb.dll which is an object from CRT.
Since the CRT is statically linked each of these module has its own copy of the CRT with it's own global state and the LLDB should not share CRT objects between them.
In this change I moved the logic of creating FILE* out of commands stream from Driver class to SBDebugger.
To do this I added new method: SBError SBDebugger::SetInputStream(SBStream &stream)
Command to build the LLDB:
cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb;libcxx" -DLLVM_USE_CRT_RELEASE="MT" -DLLVM_USE_CRT_MINSIZEREL="MT" -DLLVM_USE_CRT_RELWITHDEBINFO="MT" -DP
YTHON_HOME:FILEPATH=C:/Python38 -DCMAKE_C_COMPILER:STRING=cl.exe -DCMAKE_CXX_COMPILER:STRING=cl.exe ../llvm
Command which will fail:
lldb.exe -o help
See discord discussion for more details: https://discord.com/channels/636084430946959380/636732809708306432/854629125398724628
This revision is for the further discussion.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D104413
I don't see a reason why not to. If we allows lookup functions by full names,
I can change the test case in D113930 to use `lldb-test symbols --find=function --name=full::name --function-flags=full ...`,
though the duplicate method decl prolem is still there for `lldb-test symbols --dump-ast`.
That's a seprate bug, we can fix it later.
Differential Revision: https://reviews.llvm.org/D114467
This diff is adding the capping_size determination for the list and forward list, to limit the number of children to be displayed. Also it modifies and unifies tests for libcxx and libstdcpp list data formatter.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D114433
This diff is avoiding the size limitation introduced by the capping size for the libcxx and libcpp bitset data formatters.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D114461
We need to add checks that ensure that some core variables are valid, so
that we avoid printing out garbage data. The worst that could happen is
that an non-initialized variable is being printed as something with
123123432 children instead of 0.
Differential Revision: https://reviews.llvm.org/D114458
As suggested by @labath in https://reviews.llvm.org/D114403, we should
make the formatter more resilient to corrupted data. The Libcxx version
explicitly checks for engaged = 1, so we can do that as well for safety.
Differential Revision: https://reviews.llvm.org/D114450
Configuring lldb with `LLDB_ENABLE_PYTHON=OFF` and `LLDB_ENABLE_LUA=ON` results in a CMake error:
CMake Error at lldb/bindings/lua/CMakeLists.txt:47 (create_relative_symlink):
Unknown CMake command "create_relative_symlink".
Call Stack (most recent call first):
lldb/CMakeLists.txt:117 (finish_swig_lua)
This is because the CMake function `create_relative_symlink` only exists in `lldb/bindings/python/CMakeLists.txt`, and not in `lldb/bindings/lua/CMakeLists.txt`.
Move the function to `lldb/bindings/CMakeLists.txt`, so it is available for all language bindings.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D114465
The test flaked on bots:
http://green.lab.llvm.org/green/job/lldb-cmake/38666/
The test expects that tsan will detect a single race
with concurrent memory accesses. TSan doesn't do this reliably.
Run 100 iterations of the racing threads, which should
make the race much more likely to be detected.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D114444
LLDB uses mangled name to construct a fully qualified name for global
variables. Sometimes DW_TAG_linkage_name attribute is missing from
debug info, so LLDB has to rely on parent entries to construct the
fully qualified name.
Currently, the fallback is handled when the parent DW_TAG is either
DW_TAG_compiled_unit or DW_TAG_partial_unit, which may not work well
for global constants in namespaces. For example:
namespace ns {
const int x = 10;
}
may produce the following debug info:
<1><2a>: Abbrev Number: 2 (DW_TAG_namespace)
<2b> DW_AT_name : (indirect string, offset: 0x5e): ns
<2><2f>: Abbrev Number: 3 (DW_TAG_variable)
<30> DW_AT_name : (indirect string, offset: 0x61): x
<34> DW_AT_type : <0x3c>
<38> DW_AT_decl_file : 1
<39> DW_AT_decl_line : 2
<3a> DW_AT_const_value : 10
Since the fallback didn't handle the case when parent tag is
DW_TAG_namespace, LLDB wasn't able to match the variable by its fully
qualified name "ns::x". This change fixes this by additional check
if the parent is a DW_TAG_namespace.
Reviewed By: werat, clayborg
Differential Revision: https://reviews.llvm.org/D112147
This diff adds a data formatter and tests for libstdcpp's unordered_map, unordered_set, unordered_multimap, unordered_multiset
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D113760
Summary:
```
// Facebook only:
// We want to load automatically the fblldb python module as soon as lldb or
// lldb-vscode start. This will ensure that logging and formatters are enabled
// by default.
//
// As we want to have a mechanism for not triggering this by default, if the
// user is starting lldb disabling .lldbinit support, then we also don't load
// this module. This is equivalent to appending this line to all .lldbinit
// files.
//
// We don't have the fblldb module on windows, so we don't include it for that
// build.
```
Test Plan:
the fbsymbols module is loaded automatically
```
./bin/lldb
(lldb) help fbsymbols
Facebook {mini,core}dump utility. Expects 'raw' input (see 'help raw-input'.)
```
Reviewers: wanyi
Reviewed By: wanyi
Subscribers: mnovakovic, serhiyr, phabricatorlinter
Differential Revision: https://phabricator.intern.facebook.com/D29372804
Tags: accept2ship
Signature: 29372804:1624567770:07836e50e576bd809124ed80a6bc01082190e48f
[lldb] Load fblldbinit instead of fblldb
Summary: Once accepted, it'll merge it with the existing commit in our branch so that we keep the commit list as short as possible.
Test Plan: https://www.internalfb.com/diff/D30293094
Reviewers: aadsm, wanyi
Reviewed By: aadsm
Subscribers: mnovakovic, serhiyr
Differential Revision: https://phabricator.intern.facebook.com/D30293211
Tags: accept2ship
Signature: 30293211:1628880953:423e2e543cade107df69da0ebf458e581e54ae3a
Using an lldb_private object in the bindings involves three steps
- wrapping the object in it's lldb::SB variant
- using swig to convert/wrap that to a PyObject
- wrapping *that* in a lldb_private::python::PythonObject
Our SBTypeToSWIGWrapper was only handling the middle part. This doesn't
just result in increased boilerplate in the callers, but is also a
functionality problem, as it's very hard to get the lifetime of of all
of these objects right. Most of the callers are creating the SB object
(step 1) on the stack, which means that we end up with dangling python
objects after the function terminates. Most of the time this isn't a
problem, because the python code does not need to persist the objects.
However, there are legitimate cases where they can do it (and even if
the use case is not completely legitimate, crashing is not the best
response to that).
For this reason, some of our code creates the SB object on the heap, but
it has another problem -- it never gets cleaned up.
This patch begins to add a new function (ToSWIGWrapper), which does all
of the three steps, while properly taking care of ownership. In the
first step, I have converted most of the leaky code (except for
SBStructuredData, which needs a bit more work).
Differential Revision: https://reviews.llvm.org/D114259
This is a preparatory commit to enable mocking of qemu startup. That
will involve running the mock server in a separate process, so there's
no need for multithreading.
Initialization is moved from the start function into the constructor
(which can then take an actual socket instead of a class), and the run
method is made public.
Depends on D114156.
Differential Revision: https://reviews.llvm.org/D114157
We were using the client socket close as a way to terminate the handler
thread. But this kind of concurrent access to the same socket is not
safe. It also complicates running the handler without a dedicated thread
(next patch).
Instead, here I add an explicit way for a packet handler to request
termination. Waiting for lldb to terminate the connection would almost
be sufficient, but in the pty test we want to keep the pty open so we
can examine its state. Ability to disconnect at an arbitrary point may
be useful for testing other aspects of lldb functionality as well.
The way this works is that now each packet handler can optionally return
a list of responses (instead of just one). One of those responses (it
only makes sense for it to be the last one) can be a special
RESPONSE_DISCONNECT object, which triggers a disconnection (via a new
TerminateConnectionException).
As the mock server now cleans up the connection whenever it disconnects,
the pty test needs to explicitly dup(2) the descriptors in order to
inspect the post-disconnect state.
Differential Revision: https://reviews.llvm.org/D114156
[NFC] As part of using inclusive language within the llvm project, this patch
replaces master in these comments.
Reviewed By: clayborg, JDevlieghere
Differential Revision: https://reviews.llvm.org/D114123
This file was way more complicated than it needed to be.
This patch removes the automagic reference-to-pointer delegation and
replaces the template specializations with regular free functions
(taking reference arguments).
The reason I chose references is twofold:
- there are more arguments being passed by reference than by pointer
- the reference arguments make it more obvious that there is a lot of
leaking going on in there.
Currently, the code was assuming that the pointer arguments have some
kind of a special meaning and that pointer functions take ownership of
their arguments, which isn't true (it's possible it was true at some
point in the past, I haven't done the archeology).
This makes it easier to implement proper lifetime management in
follow-up patches.
Differential Revision: https://reviews.llvm.org/D114150
The StringPrinter class was using a Process instance to read memory.
This automatically prevented it from working before starting the
program.
This patch changes the class to use the Target object for reading
memory, as targets are always available. This required moving
ReadStringFromMemory from Process to Target.
This is sufficient to make frame/target variable work, but further
changes are necessary for the expression evaluator. Preliminary analysis
indicates the failures are due to the expression result ValueObjects
failing to provide an address, presumably because we're operating on
file addresses before starting. I haven't looked into what would it take
to make that work.
Differential Revision: https://reviews.llvm.org/D113098
This reverts commit 951b107eed.
Buildbots were failing, there is a deadlock in /Users/gclayton/Documents/src/llvm/clean/llvm-project/lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s when ELF files try to relocate things.
Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this change, the "Symbtab *ObjectFile::GetSymtab()" is no longer virtual and will end up calling a new "void ObjectFile::ParseSymtab(Symtab &symtab)" pure virtual function to actually do the parsing. This helps centralize the code for parsing the symbol table and allows the ObjectFile base class to do all of the common work, like taking the necessary locks and creating the symbol table object itself. Plug-ins now just need to parse when they are asked to parse as the ParseSymtab function will only get called once.
Differential Revision: https://reviews.llvm.org/D113965
distutils is deprecated and will be removed, so we shouldn't be
using it.
We were using it to compute LLDB_PYTHON_RELATIVE_PATH.
Discussing a similar issue
[at python.org](https://bugs.python.org/issue41282), Filipe Laíns said:
If you are relying on the value of distutils.sysconfig.get_python_lib()
as you shown in your system, you probably don't want to. That
directory (dist-packages) should be for Debian provided packages
only, so moving to sysconfig.get_path() would be a good thing,
as it has the correct value for user installed packages on your
system.
So I propose using a relative path from `sys.prefix` to
`sysconfig.get_path("platlib")` instead.
On Mac and windows, this results in the same paths as we had before,
which are `lib/python3.9/site-packages` and `Lib\site-packages`,
respectively.
On ubuntu however, this will change the path from
`lib/python3/dist-packages` to `lib/python3.9/site-packages`.
This change seems to be correct, as Filipe said above, `dist-packages`
belongs to the distribution, not us.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D114106
see: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38387/console
```
Could not find a relative path to sys.executable under sys.prefix
tried: /usr/local/opt/python/bin/python3.7
tried: /usr/local/opt/python/bin/../Frameworks/Python.framework/Versions/3.7/bin/python3.7
sys.prefix: /usr/local/Cellar/python/3.7.1/Frameworks/Python.framework/Versions/3.7
```
It was unable to find LLDB_PYTHON_EXE_RELATIVE_PATH because it was not resolving
the real path of sys.prefix.
caused by: https://reviews.llvm.org/D113650
The reworking of the gdb client tests into the PlatformClientTestBase broke
the test for this. I did the mutatis mutandis for the move, but the test
still fails. Reverting till I have time to figure out why.
This reverts commit b715b79d54.
We don't actually need a local copy of the main executable to debug
a remote process. So instead of treating "no local module" as an error,
see if the LaunchInfo has an executable it wants lldb to use, and if so
use it. Then report whatever error the remote server returns.
Differential Revision: https://reviews.llvm.org/D113521
LLDB doesn't use only the python stable ABI, which means loading
it into an incompatible python can cause the process to crash.
_lldb.so should be named with the full EXT_SUFFIX from sysconfig
-- such as _lldb.cpython-39-darwin.so -- so this doesn't happen.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D112972
Apparently "{sys.prefix}/bin/python3" isn't where you find the
python interpreter on windows, so the test I wrote for
-print-script-interpreter-info is failing.
We can't rely on sys.executable at runtime, because that will point
to lldb.exe not python.exe.
We can't just record sys.executable from build time, because python
could have been moved to a different location.
But it should be OK to apply relative path from sys.prefix to sys.executable
from build-time to the sys.prefix at runtime.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D113650
This allows for using SFINAE partial specialization for DenseMapInfo.
In MLIR, this is particularly useful as it will allow for defining partial
specializations that support all Attribute, Op, and Type classes without
needing to specialize DenseMapInfo for each individual class.
Differential Revision: https://reviews.llvm.org/D113641
Module resolution is probably the most complex piece of lldb [citation
needed], with numerous levels of abstraction, each one implementing
various retry and fallback strategies.
It is also a very repetitive, with only small differences between
"host", "remote-and-connected" and "remote-but-not-(yet)-connected"
scenarios.
The goal of this patch (first in series) is to reduce the number of
abstractions, and deduplicate the code.
One of the reasons for this complexity is the tension between the desire
to offload the process of module resolution to the remote platform
instance (that's how most other platform methods work), and the desire
to keep it local to the outer platform class (its easier to subclass the
outer class, and it generally makes more sense).
This patch resolves that conflict in favour of doing everything in the
outer class. The gdb-remote (our only remote platform) implementation of
ResolveExecutable was not doing anything gdb-specific, and was rather
similar to the other implementations of that method (any divergence is
most likely the result of fixes not being applied everywhere rather than
intentional).
It does this by excising the remote platform out of the resolution
codepath. The gdb-remote implementation of ResolveExecutable is moved to
Platform::ResolveRemoteExecutable, and the (only) call site is
redirected to that. On its own, this does not achieve (much), but it
creates new opportunities for layer peeling and code sharing, since all
of the code now lives closer together.
Differential Revision: https://reviews.llvm.org/D113487
The GetSupportedArchitectureAtIndex pattern forces the use of
complicated patterns in both the implementations of the function and in
the various callers.
This patch creates a new method (GetSupportedArchitectures), which
returns a list (vector) of architectures. The
GetSupportedArchitectureAtIndex is kept in order to enable incremental
rollout. Base Platform class contains implementations of both of these
methods, using the other method as the source of truth. Platforms
without infinite stacks should implement at least one of them.
This patch also ports Linux, FreeBSD and NetBSD platforms to the new
API. A new helper function (CreateArchList) is added to simplify the
common task of creating a list of ArchSpecs with the same OS but
different architectures.
Differential Revision: https://reviews.llvm.org/D113608
This infrastructure has proven proven its worth, so give it a more
prominent place.
My immediate motivation for this is the desire to reuse this
infrastructure for qemu platform testing, but I believe this move makes
sense independently of that. Moving this code to the packages tree will
allow as to add more structure to the gdb client tests -- currently they
are all crammed into the same test folder as that was the only way they
could access this code.
I'm splitting the code into two parts while moving it. The first once
contains just the generic gdb protocol wrappers, while the other one
contains the unit test glue. The reason for that is that for qemu
testing, I need to run the gdb code in a separate process, so I will
only be using the first part there.
Differential Revision: https://reviews.llvm.org/D113893
It is great to know how many times the target has stopped over its lifetime as each time the target stops, and possibly resumes without the user seeing it for things like shared library loading and signals that are not notified and auto continued, to help explain why a debug session might be slow. This is now included as "stopCount" inside each target JSON.
Differential Revision: https://reviews.llvm.org/D113810
This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.
As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D110216
`image lookup -a ` doesn't work because the compilands list is always empty.
Create CU at given index if doesn't exit.
Differential Revision: https://reviews.llvm.org/D113821
The value type can be a typedef of a reference (e.g. `typedef int& myint`).
In this case `GetQualType(type)` will return `clang::Typedef`, which cannot
be casted to `clang::ReferenceType`.
Fix a regression introduced in https://reviews.llvm.org/D103532.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D113673
D112976 changed the layout and 0d62e31c45 andjusted the test
expectations to match.
This patch changes the tests to expect both versions, so that one can
run the test suite against older libc++ versions as well.
This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.
As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D110216
[NFC] As part of using inclusive language within the llvm project, this patch
replaces `m_master` in `ASTImporterDelegate` with `m_main`.
Reviewed By: teemperor, clayborg
Differential Revision: https://reviews.llvm.org/D113720
[NFC] This patch replaces master and slave with primary and secondary
respectively when referring to pseudoterminals/file descriptors.
Reviewed By: clayborg, teemperor
Differential Revision: https://reviews.llvm.org/D113687
When LLDB receives a SIGINT while running the embedded Python REPL it currently
just crashes in `ScriptInterpreterPythonImpl::Interrupt` with an error such as
the one below:
```
Fatal Python error: PyThreadState_Get: the function must be called with the GIL
held, but the GIL is released (the current Python thread state is NULL)
```
The faulty code that causes this error is this part of `ScriptInterpreterPythonImpl::Interrupt`:
```
PyThreadState *state = PyThreadState_GET();
if (!state)
state = GetThreadState();
if (state) {
long tid = state->thread_id;
PyThreadState_Swap(state);
int num_threads = PyThreadState_SetAsyncExc(tid, PyExc_KeyboardInterrupt);
```
The obvious fix I tried is to just acquire the GIL before this code is running
which fixes the crash but the `KeyboardInterrupt` we want to raise immediately
is actually just queued and would only be raised once the next line of input has
been parsed (which e.g. won't interrupt Python code that is currently waiting on
a timer or IO from what I can see). Also none of the functions we call here is
marked as safe to be called from a signal handler from what I can see, so we
might still end up crashing here with some bad timing.
Python 3.2 introduced `PyErr_SetInterrupt` to solve this and the function takes
care of all the details and avoids doing anything that isn't safe to do inside a
signal handler. The only thing we need to do is to manually setup our own fake
SIGINT handler that behaves the same way as the standalone Python REPL signal
handler (which raises a KeyboardInterrupt).
From what I understand the old code used to work with Python 2 so I kept the old
code around until we officially drop support for Python 2.
There is a small gap here with Python 3.0->3.1 where we might still be crashing,
but those versions have reached their EOL more than a decade ago so I think we
don't need to bother about them.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D104886
[NFC] As part of using inclusive language within the llvm project, this patch
renames master plan to controlling plan in lldb.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D113019
This adds a specific unwind plan for AArch64 Linux sigreturn frames.
Previously we assumed that the fp would be valid here but it is not.
https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/vdso/sigreturn.S
On Ubuntu Bionic it happened to point to an old frame info which meant
you got what looked like a correct backtrace. On Focal, the info is
completely invalid. (probably due to some code shuffling in libc)
This adds an UnwindPlan that knows that the sp in a sigreturn frame
points to an rt_sigframe from which we can offset to get saved
sp and pc values to backtrace correctly.
Based on LibUnwind's change: https://reviews.llvm.org/D90898
A new test is added that sets all compares the frames from the initial
signal catch to the handler break. Ensuring that the stack/frame pointer,
function name and register values match.
(this test is AArch64 Linux specific because it's the only one
with a specific unwind plan for this situation)
Fixes https://bugs.llvm.org/show_bug.cgi?id=52165
Reviewed By: omjavaid, labath
Differential Revision: https://reviews.llvm.org/D112069
This is part of https://github.com/dlang/projects/issues/81 .
This patch enables support for D programming language demangler by using a
pretty printed stacktrace with demangled D symbols, when present.
Signed-off-by: Luís Ferreira <contact@lsferreira.net>
Reviewed By: JDevlieghere, teemperor
Differential Revision: https://reviews.llvm.org/D110578
This patch changes the ScriptedThread class to create the register
context when Process::RefreshStateAfterStop is called rather than
doing it in the thread constructor.
This is required to update the thread state for execution control.
Differential Revision: https://reviews.llvm.org/D112167
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
D112976 moved most of the guts of __vector_base into vector, this broke
some LLDB tests by changing the result types that LLDB sees. This updates
the test to reflect the new structure.
Teach LLDB to understand INLINE and INLINE_ORIGIN records in breakpad.
They have the following formats:
```
INLINE inline_nest_level call_site_line call_site_file_num origin_num [address size]+
INLINE_ORIGIN origin_num name
```
`INLNIE_ORIGIN` is simply a string pool for INLINE so that we won't have
duplicated names for inlined functions and can show up anywhere in the symbol
file.
`INLINE` follows immediately after `FUNC` represents the ranges of momery
address that has functions inlined inside the function.
Differential Revision: https://reviews.llvm.org/D113330
Because TestScriptedProcess.py creates a skinny corefile to provides data
to the ScriptedProcess and ScriptedThread, we need to make sure that the
debugserver used is not out of tree, to ensure feature availability
between debugserver and lldb.
This also removes the `SKIP_SCRIPTED_PROCESS_LAUNCH` env variable after
each test finish running.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Since every FUNC record (in breakpad) is a compilation unit, creating the
function for the CU allows `ResolveSymbolContext` to resolve
`eSymbolContextFunction`.
Differential Revision: https://reviews.llvm.org/D113163
This reverts commit 3bf96b0329.
It causes crashes as reported in PR52257 and a few other places. A reproducer is bundled with this commit to verify any fix forward. The original test is left in place, but marked XFAIL as it now produces the wrong result.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D113449
It is surprisingly difficult to write a simple python script that
can reliably `import lldb` without failing, or crashing. I'm
currently resorting to convolutions like this:
def find_lldb(may_reexec=False):
if prefix := os.environ.get('LLDB_PYTHON_PREFIX'):
if os.path.realpath(prefix) != os.path.realpath(sys.prefix):
raise Exception("cannot import lldb.\n"
f" sys.prefix should be: {prefix}\n"
f" but it is: {sys.prefix}")
else:
line1, line2 = subprocess.run(
['lldb', '-x', '-b', '-o', 'script print(sys.prefix)'],
encoding='utf8', stdout=subprocess.PIPE,
check=True).stdout.strip().splitlines()
assert line1.strip() == '(lldb) script print(sys.prefix)'
prefix = line2.strip()
os.environ['LLDB_PYTHON_PREFIX'] = prefix
if sys.prefix != prefix:
if not may_reexec:
raise Exception(
"cannot import lldb.\n" +
f" This python, at {sys.prefix}\n"
f" does not math LLDB's python at {prefix}")
os.environ['LLDB_PYTHON_PREFIX'] = prefix
python_exe = os.path.join(prefix, 'bin', 'python3')
os.execl(python_exe, python_exe, *sys.argv)
lldb_path = subprocess.run(['lldb', '-P'],
check=True, stdout=subprocess.PIPE,
encoding='utf8').stdout.strip()
sys.path = [lldb_path] + sys.path
This patch aims to replace all that with:
#!/usr/bin/env lldb-python
import lldb
...
... by adding the following features:
* new command line option: --print-script-interpreter-info. This
prints language-specific information about the script interpreter
in JSON format.
* new tool (unix only): lldb-python which finds python and exec's it.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D112973
This patch changes the ScriptedProcess test to use a stack-only skinny
corefile as a backing store.
The corefile is saved as a temporary file at the beginning of the test,
and a second target is created for the ScriptedProcess. To do so, we use
the SBAPI from the ScriptedProcess' python script to interact with the
corefile process.
This patch also makes some small adjustments to the other ScriptedProcess
scripts to resolve some inconsistencies and removes the raw memory dump
that was previously checked in.
Differential Revision: https://reviews.llvm.org/D112047
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch changes the `ScriptedThread` initializer in couple of ways:
- It replaces the `SBTarget` parameter by a `SBProcess` (pointing to the
`ScriptedProcess` that "owns" the `ScriptedThread`).
- It adds a reference to the `ScriptedProcessInfo` Dictionary, to pass
arbitrary user-input to the `ScriptedThread`.
This patch also fixes the SWIG bindings methods that call the
`ScriptedProcess` and `ScriptedThread` initializers by passing all the
arguments to the appropriate `PythonCallable` object.
Differential Revision: https://reviews.llvm.org/D112046
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds a new `StructuredData::Dictionary` constructor that
takes a `StructuredData::ObjectSP` as an argument. This is used to pass
the opaque_ptr from the `SBStructuredData` used to initialize a
ScriptedProecss, to the `ProcessLaunchInfo` class.
This also updates `SBLaunchInfo::SetScriptedProcessDictionary` to
reflect the formentionned changes which solves the nullptr deref.
Differential Revision: https://reviews.llvm.org/D112107
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Ben Jackson