These can come out nondeterministically for two reasons:
- sorting based on ConstStringified pointer values
- different relative speeds of the indexing threads
Making these nondeterministic without incurring performance penalties is
hard, so I just make the test expect them in any order (the order is not
important in this test anyway.
Seems like this code raised some alarm bells as it looks like an ArrayRef
to a temporary initializer list, but it's actually just calling the ArrayRef(T*, T*)
constructor. Let's clarify this and directly call the right ArrayRef constructor here.
Fixes rdar://problem/59176052
Summary:
I added an `abort()` call to some code and noticed that the test suite was still passing and it just marked my test as "UNSUPPORTED".
It seems the reason for that is that we expect failing tests to print "FAIL:" which doesn't happen when we crash. If we then also
have an unsupported because we skipped some debug information in the output, we just mark the test passing because it is unsupported
on the current platform.
This patch marks any test that has a non-zero exit code as failing even if it doesn't print "FAIL:" (e.g., because it crashed).
Reviewers: labath, JDevlieghere
Reviewed By: labath, JDevlieghere
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D75031
These are technically text files, but the object file layer treats them
as binary, and the relevant tests verify the parsed contents byte for
byte. Git's crlf conversion can make those tests fail. Marking the files
as non-text disables that.
Order of evaluation of the operands of any C++ operator [...] is
unspecified. This patch fixes the issue in Stream::Indent by calling the
function consecutively.
On my Windows setup, TestSettings.py fails because the function prints
the value first, followed by the indentation.
Expected result:
MY_FILE=this is a file name with spaces.txt
Actual result:
MY_FILE =this is a file name with spaces.txt
The aarcht64-ubuntu bot is showing a test failure in TestHandleAbort.py
with this patch. Adding some logging to that file, it looks like
the saved register context above the trap handler does not have
save state for $pc, but it does have it for $lr on that platform.
I need to fall back to looking for $lr if the $pc cannot be retrieved.
I'll update the patch and re-commit once that's fixed.
This reverts commit edc4f4c9c9.
Fix RegisterContextLLDB::InitializeNonZerothFrame so that it
will fetch a FullUnwindPlan instead of falling back to the
architectural default unwind plan -- GetFullUnwindPlan knows
how to spot a jmp 0x0 that results in a fault, which may be
the case when we see a trap handler on the stack.
Fix RegisterContextLLDB::SavedLocationForRegister so that when
the pc value is requested from a trap handler frame, where we
have a complete register context available to us, don't provide
the Return Address register (lr) instead of the pc. We have
an actual pc value here, and it's pointing to the instruction
that faulted.
Differential revision: https://reviews.llvm.org/D75007
<rdar://problem/59416588>
Highlight the color marker similar to what we do for the column marker.
The default color matches the color of the current PC marker (->) in the
default disassembly format.
Differential revision: https://reviews.llvm.org/D75070
This patch moves the SB API method GetExtendedCrashInformation from
SBTarget to SBProcess since it only makes sense to call this method on a
sane process which might not be the case on a SBTarget object.
It also addresses some feedbacks received after landing the first patch
for the 'crash-info' feature.
Differential Revision: https://reviews.llvm.org/D75049
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
The convention is that the dwp file name is derived from the name of the
file holding the executable code, even if the linked portion of the
debug info is elsewhere (objcopy --only-keep-debug).
Summary:
Currently the test suite runs with enabled automatically applied Clang fix-its for expressions.
This is causing that sometimes incorrect expressions in tests are still evaluated even though they
are actually incorrect. Let's disable this feature in the test suite so that we know when expressions
are wrong and leave the fix-it testing to the dedicated tests for that feature.
Also updates the `lang/cpp/operators/` test as it seems Clang needs the `struct` keywords
before C and would otherwise fail without fixits.
Reviewers: jingham, JDevlieghere, shafik
Reviewed By: JDevlieghere, shafik
Subscribers: shafik, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74957
Explicit dynsym/dynstr sections were added in a6370d5 to compensate for
a yaml2obj change D74764. This test doesn't need those sections, so
instead I just delete the explicit section blocks, and also the
"DynamicSymbols" block, which triggers their implicit generation.
Summary:
When we added support for type units in dwo files, we changed the
"manual" dwarf index to index _all_ dwarf units in the dwo file instead
of just the split unit belonging to our skeleton unit. This was fine for
dwo files, as they contain only a single compile units and type units do
not have a split type unit which would point to them.
However, this does not work for dwp files because, these files do
contain multiple split compile units, and the current approach means
that each unit gets indexed multiple times (once for each split unit =>
n^2 complexity).
This patch teaches the manual dwarf index to treat dwp files specially.
Any type units in the dwp file added to the main list of compile units
and indexed with them in a single batch. Split compile units in dwp
files are still indexed as a part of their skeleton unit -- this is done
because we need the DW_AT_language attribute from the skeleton unit to
index them properly.
Handling of dwo files remains unchanged -- all units (type and skeleton)
are indexed when we reach the dwo file through the split unit.
Reviewers: clayborg, JDevlieghere, aprantl
Subscribers: arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74964
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
D74764 (https://reviews.llvm.org/rG31f2ad9c368d47721508cbd0d120d626f9041715)
changed the behavior of the yaml2obj. Now it assigns virtual addresses
for allocatable sections.
SymbolFile/Breakpad/symtab.test started to fail after this change:
(http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/5520/steps/test/logs/stdio)
Command Output (stderr):
--
/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/Shell/SymbolFile/Breakpad/symtab.test:6:10: error: CHECK: expected string not found in input
# CHECK: Symtab, file = {{.*}}symtab.out, num_symbols = 5:
^
<stdin>:15:1: note: scanning from here
Symtab, file = /home/worker/lldb-x86_64-debian/lldb-x86_64-debian/build/tools/lldb/test/SymbolFile/Breakpad/Output/symtab.out, num_symbols = 6:
^
<stdin>:15:99: note: possible intended match here
Symtab, file = /home/worker/lldb-x86_64-debian/lldb-x86_64-debian/build/tools/lldb/test/SymbolFile/Breakpad/Output/symtab.out, num_symbols = 6:
For now I've updated the basic-elf.yaml so that now it produce the same layout as before D74764.
Breakpad/symtab.test should be updated it seems.
Summary:
This is another attempt of 0bb90628b5.
The difference is that g_python_home is not declared as const. Since
some versions of python do not expect that.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74998
On Apple platforms, is __arm__ isn't defined and we're not on Intel, we use an
alternate std::string layout. I.e., the libcxx string test fails on phones
because the hand-crafted "garbage" string structs are actually valid strings.
See:
```
// _LIBCPP_ALTERNATE_STRING_LAYOUT is an old name for
// _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT left here for backward compatibility.
#if (defined(__APPLE__) && !defined(__i386__) && !defined(__x86_64__) && \
(!defined(__arm__) || __ARM_ARCH_7K__ >= 2)) || \
defined(_LIBCPP_ALTERNATE_STRING_LAYOUT)
#define _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
#endif
```
Disable inspection of the garbage structs on Apple+ARM devices.
Currently, in macOS, when a process crashes, lldb halts inside the
implementation disassembly without yielding any useful information.
The only way to get more information is to detach from the process, then wait
for ReportCrash to generate a report, find the report, then see what error
message was included in it. Instead of waiting for this to happen, lldb could
locate the error_string and make it available to the user.
This patch addresses this issue by enabling the user to fetch extended
crash information for crashed processes using `process status --verbose`.
Depending on the platform, this will try to gather different crash information
into an structured data dictionnary. This dictionnary is generic and extensible,
as it contains an array for each different type of crash information.
On Darwin Platforms, lldb will iterate over each of the target's images,
extract their `__crash_info` section and generated a StructuredData::Array
containing, in each entry, the module spec, its UUID, the crash messages
and the abort cause. The array will be inserted into the platform's
`m_extended_crash_info` dictionnary and `FetchExtendedCrashInformation` will
return its JSON representation like this:
```
{
"crash-info annotations": [
{
"abort-cause": 0,
"image": "/usr/lib/system/libsystem_malloc.dylib",
"message": "main(76483,0x1000cedc0) malloc: *** error for object 0x1003040a0: pointer being freed was not allocated",
"message2": "",
"uuid": "5747D0C9-900D-3306-8D70-1E2EA4B7E821"
},
...
],
...
}
```
This crash information can also be fetched using the SB API or lldb-rpc protocol
using SBTarget::GetExtendedCrashInformation().
rdar://37736535
Differential Revision: https://reviews.llvm.org/D74657
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Since the `platform process` commamnd has more tests now, this commits
separates each of the `platform process` subcommand's test in its own directory.
Differential Revision: https://reviews.llvm.org/D74836
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
This change allows a hard coded relative PYTHONHOME setting. So that
python can easily be packaged together with lldb.
The change includes:
1. Extend LLDB_RELOCATABLE_PYTHON to all platforms. It defaults to ON
for platforms other than Windows, to keep the behavior compatible.
2. Allows to customize LLDB_PYTHON_HOME. But still defaults to
PYTHON_HOME.
3. LLDB_PYTHON_HOME can be a path relative to liblldb. If it is
relative, we will resolve it before send it to Py_DecodeLocale.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74727
Summary:
The purpose of this patch is to make identifying missing dependencies clearer to the user.
`find_package` will report if a package is not found, that output, combined with the exiting
status message, is clearer than not having the additional verbosity.
If the SWIG dependency is required {LLDB_ENABLE_PYTHON, LLDB_ENABLE_LUA}
and SWIG is not available, fail the configuration step. Terminate the
configure early rather than later with a clear error message.
We could possibly modify:
`llvm-project/lldb/cmake/modules/FindPythonInterpAndLibs.cmake`
However, the patch here seems clear in my opinion.
Reviewers: aadsm, hhb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: labath, jrm, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74917
This change will bring lldb-vscode in line with how several other llvm
tools process command line arguments and make it easier to add future
options.
Differential revision: https://reviews.llvm.org/D74798
Summary:
lldb's format string (line one) is:
`lldb version $clang_version ($lldb_repo revision $lldb_revision)`
When only using $lldb_revision and not $lldb_repo, this might look like:
`lldb version 11 ( revision 12345)`
which looks pretty ugly.
Aside: I'm not sure we really need all the different versions since we've moved to the monorepo layout -- I don't think anyone is using different llvm/clang/lldb revisions, are they? We could likely tidy this up further if we knew how people consumed the output of lldb --version.
Reviewers: labath, JDevlieghere, friss
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74859
Summary:
Requesting registers one by one takes a while in our project.
We want to get rid of it by using target.xml.
Reviewers: jarin, labath, omjavaid
Reviewed By: labath, omjavaid
Subscribers: omjavaid, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74217
Summary: The logic of the sentence made more sense when "with" is replaced with "without".
Reviewers: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74895
Change the return value of SymbolFileDWARF::DebugInfo from a pointer to
a reference, and remove all null checks.
Previously, we were not constructing the DebugInfo object when the
debug_info section was empty. Now we always construct the object but
it will return an empty list of dwarf units (a thing which it already
supported).
Summary:
Around a third of our test sources have LLVM license headers. This patch removes those headers from all test
sources and also fixes any tests that depended on the length of the license header.
The reasons for this are:
* A few tests verify line numbers and will start failing if the number of lines in the LLVM license header changes. Once I landed my patch for valid SourceLocations in debug info we will probably have even more tests that verify line numbers.
* No other LLVM project is putting license headers in its test files to my knowledge.
* They make the test sources much more verbose than they have to be. Several tests have longer license headers than the actual test source.
For the record, the following tests had their line numbers changed to pass with the removal of the license header:
lldb-api :: functionalities/breakpoint/breakpoint_by_line_and_column/TestBreakpointByLineAndColumn.py
lldb-shell :: Reproducer/TestGDBRemoteRepro.test
lldb-shell :: Reproducer/TestMultipleTargets.test
lldb-shell :: Reproducer/TestReuseDirectory.test
lldb-shell :: ExecControl/StopHook/stop-hook-threads.test
lldb-shell :: ExecControl/StopHook/stop-hook.test
lldb-api :: lang/objc/exceptions/TestObjCExceptions.py
Reviewers: #lldb, espindola, JDevlieghere
Reviewed By: #lldb, JDevlieghere
Subscribers: emaste, aprantl, arphaman, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74839
TestCPPAuto was only failing on windows due to the std::string
copying (which was not related at all to 'auto' functionality).
TestStepTarget is now also passing but that seems more that we
now have by accident the right behavior in Windows. I'll remove
the x-fail just to make the bot green again.
The only thing needed was to account for the offset from the
debug_cu_index section when searching for the location list.
This patch also fixes a bug in the Module::ParseAllDebugSymbols
function, which meant that we would only parse the variables of the
first compile unit in the module. This function is only used from
lldb-test, so this does not fix any real issue, besides preventing me
from writing a test for this patch.
Comparing those two `const char *` values relies on the assumption that both
strings were created by a ConstString. Let's check that assumption with an
assert as otherwise this code silently does nothing and that's not great.
This should use -> instead of '.', but the fix-it functionality of
the expression evaluator saved us here. Let's use the proper syntax
in the first place as we don't want to test fix-its here.
This directory escaped the modularization effort it seems. Just adding
this to the Host module along with the other common headers, which should
make this code less likely to break under modules and speed up compilation.
Summary:
Currently when printing data types we include implicit scopes such as inline namespaces or anonymous namespaces.
This leads to command output like this (for `std::set<X>` with X being in an anonymous namespace):
```
(lldb) print my_set
(std::__1::set<(anonymous namespace)::X, std::__1::less<(anonymous namespace)::X>, std::__1::allocator<(anonymous namespace)::X> >) $0 = size=0 {}
```
This patch removes all the implicit scopes when printing type names in TypeSystemClang::GetDisplayTypeName
so that our output now looks like this:
```
(lldb) print my_set
(std::set<X, std::less<X>, std::allocator<X> >) $0 = size=0 {}
```
As previously GetDisplayTypeName and GetTypeName had the same output we actually often used the
two as if they are the same method (they were in fact using the same implementation), so this patch also
fixes the places where we actually want the display type name and not the actual type name.
Note that this doesn't touch the `GetTypeName` class that for example the data formatters use, so this patch
is only changes the way we display types to the user. The full type name can also still be found when passing
'-R' to see the raw output of a variable in case someone is somehow interested in that.
Partly fixes rdar://problem/59292534
Reviewers: shafik, jingham
Reviewed By: shafik
Subscribers: christof, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74478
All calls to operator new in this test fail for me with:
```
expression --show-types -- *(new foo(47))`
Error output:
error: Execution was interrupted, reason: internal c++ exception breakpoint(-6)..
The process has been returned to the state before expression evaluation.
```
As calling operator new isn't the idea of this test, this patch moves that
logic to the binary with some new_* utility functions and explicitly tests
this logic in the constructor test (where we can isolate the failures and
skip them on Linux).
The PluginManager contains a lot of duplicate code. I already removed a
bunch of it by introducing the templated PluginInstance class, and this
is the next step. The PluginInstances class combines the mutex and the
vector and implements the common operations.
To accommodate plugin instances with additional members it is possible
to access the underlying vector and mutex. The methods to query these
fields make use of that.
Differential revision: https://reviews.llvm.org/D74816
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.
Previous attempts to land this failed on the Windows bot because there's
a dependency between the different process plugins. Apparently
ProcessWindowsCommon needs to be initialized after all other process
plugins but before ProcessGDBRemote.
Differential revision: https://reviews.llvm.org/D73067
The plugin manager had dedicated Get*PluginCreateCallbackForPluginName
methods for each type of plugin, and only a small subset of those were
used. This removes the dead duplicated code.
The WASM and Hexagon plugin check the ArchType rather than the OSType,
so explicitly reject those in the DynamicLoaderStatic.
Differential revision: https://reviews.llvm.org/D74780
Generate the LLDB_PLUGIN_DECLARE macros with CMake and a def file. I'm
landing D73067 in pieces so I can bisect what exactly is breaking the
Windows bot.
Other plugins depend on DynamicLoaderDarwinKernel and which means we
cannot conditionally enable/build this plugin based on the target
platform. This means that it will be past of the list of plugins
initialized once that's autogenerated.
The two classes are equivalent, except:
- the former uses a llvm::SmallVector (with a configurable size), while
the latter uses std::vector.
- the former has a typo in one of the functions name
This patch just leaves one class, using llvm::SmallVector, and defaults
the small size to zero. This is the same thing we did with the
RangeDataVector class in D56170.
This patch enables the debug entry values feature.
- Remove the (CC1) experimental -femit-debug-entry-values option
- Enable it for x86, arm and aarch64 targets
- Resolve the test failures
- Leave the llc experimental option for targets that do not
support the CallSiteInfo yet
Differential Revision: https://reviews.llvm.org/D73534
Summary:
Follow up to an issue pointed out in the review of D73808. We shouldn't just pass in a nullptr TypeSourceInfo
in case Clang decided to access it.
Reviewers: shafik, vsk
Reviewed By: shafik, vsk
Subscribers: kristof.beyls, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73946
Pass TargetSP to filters' CreateFromStructuredData, don't let them guess
whether target object is managed by a shared_ptr.
Make Breakpoint sure that m_target.shared_from_this() is safe by passing TargetSP
to all its static Create*** member-functions. This should be enough, since Breakpoint's
constructors are private/protected and never called directly (except by Target itself).
Since f9568a9549 this function takes a
CompilerDeclContext reference instead of a pointer. It overlooked this function
when I fixed the compilation for FindTypes.
Summary:
Currently the data formatter is treating `std::atomic` variables as transparent wrappers
around their underlying value type. This causes that when printing `std::atomic<A *>`, the data
formatter will forward all requests for the children of the atomic variable to the `A *` pointer type
which will then return the respective members of `A`. If `A` in turn has a member that contains
the original atomic variable, this causes LLDB to infinitely recurse when printing an object with
such a `std::atomic` pointer member.
We could implement a workaround similar to whatever we do for pointer values but this patch
just implements the `std::atomic` formatter in the same way as we already implement other
formatters (e.g. smart pointers or `std::optional`) that just model the contents of the as a child
"Value". This way LLDB knows when it actually prints a pointer and can just use its normal
workaround if "Value" is a recursive pointer.
Fixes rdar://59189235
Reviewers: JDevlieghere, jingham, shafik
Reviewed By: shafik
Subscribers: shafik, christof, jfb, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74310
Summary:
In dwp files a constant (from the debug_cu_index section) needs to be
added to each reference into the debug_str_offsets section.
I've tried to implement this to roughly match the llvm flow: I've
changed the DWARFormValue to stop resolving the indirect string
references directly -- instead, it calls into DWARFUnit, which resolves
this for it (similar to how it already resolves indirect range and
location list references). I've also done a small refactor of the string
offset base computation code in DWARFUnit in order to make it easier to
access the debug_cu_index base offset.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74723
This should be just the enum type but that's a larger refactoring, so document that
this is not just an integer until we can make this just the type of the enum.
Summary:
All of our lookup APIs either use `CompilerDeclContext &` or `CompilerDeclContext *` semi-randomly it seems.
This leads to us constantly converting between those two types (and doing nullptr checks when going from
pointer to reference). It also leads to the confusing situation where we have two possible ways to express
that we don't have a CompilerDeclContex: either a nullptr or an invalid CompilerDeclContext (aka a default
constructed CompilerDeclContext).
This moves all APIs to use references and gets rid of all the nullptr checks and conversions.
Reviewers: labath, mib, shafik
Reviewed By: labath, shafik
Subscribers: shafik, arphaman, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74607
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
Use LLDB_PLUGIN_DEFINE_ADV to make the name of the generated initializer
match the name of the plugin. This is a step towards generating the
initializers with a def file. I'm landing this change in pieces so I can
narrow down what exactly breaks the Windows bot.
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.
The previously landed patch got reverted because it was lacking:
(1) A plugin definition for the Objective-C language runtime,
(2) The dependency between the Static and WASM dynamic loader,
(3) Explicit initialization of ScriptInterpreterNone for lldb-test.
All issues have been addressed in this patch.
Differential revision: https://reviews.llvm.org/D73067
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.
Differential revision: https://reviews.llvm.org/D73067
As discussed in https://reviews.llvm.org/D73206#1871895 there is both
`DIERef` and `user_id_t` and sometimes (for DWZ) we need to encode Main
CU into them and sometimes we cannot as it is unavailable at that point
and at the same time not even needed.
I have also noticed `DIERef` and `user_id_t` in fact contain the same
information which can be seen in SymbolFileDWARF::GetUID.
SB* API/ABI is already using `user_id_t` and it needs to encode Main CU
for DWZ. Therefore what about making `DIERef` the identifier not
containing Main CU and `user_id_t` the identifier containing Main CU?
It is sort of a revert of D63322.
I find this patch as a NFC cleanup to the codebase - to satisfy a new
premise `user_id_t` is used as little as possible and thus only for
external interfaces which must not deal with MainCU in any way.
Its larger goal is to satisfy a plan to implement DWZ support.
Differential Revision: https://reviews.llvm.org/D74637
The error is: no matching function for call to 'transform(std::string&, std::__cxx11::basic_string<char>::iterator, <unresolved overloaded function type>)'
The fix: replace llvm::transform with an equally simple hand-rolled
loop.
Summary:
This patch removes the bitrotted SymbolFileDWARF(Dwo)Dwp classes, and
replaces them with dwp support implemented directly inside
SymbolFileDWARFDwo, in a manner mirroring the implementation in llvm.
This patch does:
- add support for the .debug_cu_index section to our DWARFContext
- adds a llvm::DWARFUnitIndex argument to the DWARFUnit constructors.
This argument is used to look up the offsets of the debug_info and
debug_abbrev contributions in the sections of the dwp file.
- makes sure the creation of the DebugInfo object as well as the initial
discovery of DWARFUnits is thread-safe, as we can now call this
concurrently when doing parallel indexing.
This patch does not:
- use the DWARFUnitIndex to search for other kinds of contributions
(debug_loc, debug_ranges, etc.). This means that units which reference
these sections will not work correctly. These will be handled by
follow-up patches, but even the present level of support is sufficient
to enable basic functionality.
- Make the llvm::DWARFContext thread-safe. Right now, it just avoids this
problem by ensuring everything is initialized ahead of time. However,
this is something we will run into more often as we try to use more of
llvm, and so I plan to start looking into our options here.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: mgorny, mgrang, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73783
Summary:
These definitions are used to "augment" information received from the remote
target with eh/debug frame and "generic" register numbers.
Besides being verbose, this information was also incomplete (new registers like
xmm16-31 were missing) and sometimes even downright wrong (ymm register
numbers).
Most of this information is available via llvm's MCRegisterInfo. This patch
creates a new class, MCBasedABI, which retrieves the eh and debug frame register
numbers this way. The tricky part here is that the llvm class uses all-caps
register names, whereas lldb register are lowercase, and sometimes called
slightly differently. Therefore this class introduces some hooks to allow a
subclass to customize the MC lookup. The subclass also needs to suply the
"generic" register numbers, as this is an lldb invention.
This patch ports the x86_64 ABI classes to use the new register info mechanism.
It also creates a new "ABIx86_64" class which can be used to house code common
to x86_64 both ABIs. Right now, this just consists of a single function, but
there are plenty of other things that could be moved here too.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74244
Summary:
Synthesize target.xml in lldb-server to avoid a long chain of
qRegisterInfo packets, which can be slow over low-latency links.
Reviewers: jarin, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74217
As discussed in https://reviews.llvm.org/D73206#1871895> simplifying
usage of `user_id_t`.
There is even written:
// The compile unit ID is the index of the DWARF unit.
DWARFUnit *dwarf_cu = info->GetUnitAtIndex(comp_unit->GetID());
Differential Revision: https://reviews.llvm.org/D74670
Commit 82b47b2978 changes the way the stdlib.h
header is structured which seems to cause strange lookup failures in the modules
build. This updates a few failing tests so that they pass with the new
behavior of stdlib.h.
See the discussion in https://reviews.llvm.org/rG82b47b2978405f802a33b00d046e6f18ef6a47be
SB API clients can describe the failure message in a more natural
way for their UI, this doesn't add information for them.
Differential Revision: https://reviews.llvm.org/D74585
<rdar://problem/49953304>
In 0e9b0b6d11 I introduced the
HistoryOperation enum to navigate the history. While this fixed the
behavior of HistoryOperation::Older and HistoryOperation::Newer, it
confused the mapping for HistoryOperation::Oldest and
HistoryOperation::Newest.
I tried to write a PExpect test to make sure this doesn't regress, but
I'm unable to prime the history in such a way that it recalls a known
element. I suspect this is an LLDB bug, but the most recent entry
doesn't get update with entries from the current session. I considered
spoofing the home directory but that needs to happen before libLLDB is
loaded and you'll need to account for the widechar support. If anyone
has another suggestion I'd love to hear it.
This is the second dwp preparatory patch. When a SymbolFileDWARFDwo will
hold more than one split unit, it will not be able to be uniquely owned
by a single DWARFUnit. I achieve this by changing the
unique_ptr<SymbolFileDWARFDwo> member of DWARFUnit to
shared_ptr<DWARFUnit>. The shared_ptr points to a DWARFUnit, but it is
in fact holding the entire SymbolFileDWARFDwo alive. This is the same
method used by llvm DWARFUnit (except that is uses the DWARFContext
class).
Differential Revision: https://reviews.llvm.org/D73782
Summary:
This was added in 2018 (r339929), when we were still using the
hand-rolled test runner.
It does not seem to be relevant anymore. In fact as far as I can tell,
it's a big no-op now as the exclusive_test_subdir variable is never set.
Reviewers: vsk, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74551
This reverts b3a0c4d7dc for
TestBreakpointHitCount.py because it's now timing out on the Windows
bot. I'm not sure this is the cause, but the substitution doesn't look
correct anyway...
After the recent change that grouped some of the ABI plugins together,
those plugins ended up with multiple initializers per plugin. This is
incompatible with my proposed approach of generating the initializers
dynamically, which is why I've grouped them together in a new entry
point.
Differential revision: https://reviews.llvm.org/D74451
Mach allows you to suspend and resume other threads within a program, so
debugserver has to be careful not to interfere with this when it goes to supend and
resume threads while stepping over breakpoints and calling functions. Even
trickier, if you call a function on a suspended thread, it has to resume the
thread to get the expression to run, and then suspend it properly when done.
This all works already, but there wasn't a test for it. Adding that here.
This same test could be written for a unix that supports pthread_{suspend,resume}_np, but
macOS doesn't support these calls, only the mach version. It doesn't look like
a lot of Linux'es support this (AIX does apparently...) And IIUC Windows allows
you to suspend and resume other threads, but the code for that would look pretty
different than this main.c. So for simplicity's sake I wrote this test for Darwin-only.
Summary:
This patch fixes logging to log incoming packets which was removed during a refactor.
We also enable logging to a "vscode.txt" file for each lldb-vscode test by creating the log file in the build artifacts directory for each test. This allows users to see the packets for their tests if needed and the log file is in a directory that will be removed after tests have been run.
Reviewers: labath, aadsm, serhiy.redko, jankratochvil, xiaobai, wallace
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74566
This commit fixes an issue with lldb-vscode failing to run programs that
use different architecture/platform than the "empty" in the target.
Original implementation was creating a default target without specifying
the target architecture, platform or program, and then would set
executable file through SBLaunchInfo, assuming that this would update
architecture and platform accordingly. However this wasn't really
happening, and architecture and platform would remain at whatever values
were in the "empty" target. The simple solution is to create target
already for a desired architecture and platform.
Function request_attach is updated in a similar fashion.
This commit also adds new JSON properties to "launch" and "attach"
packets to allow user to override desired platform and architecture.
This might be especially important for cases where information in ELF is
not enough to derive those values correctly.
New code has a behavior similar to LLDB MI [1], where typically IDE would
specify target file with -file-exec-and-symbols, and then only do -exec-run
command that would launch the process. In lldb-vscode those two actions are
merged into one request_launch function. Similarly in the interpreter
session, user would first do "file" command, then "process launch"
Differential Revision: https://reviews.llvm.org/D70847
Signed-off-by: Anton Kolesov <anton.kolesov@synopsys.com>
Summary: The VS Code DAP expects on response for each breakpoint that was requested. If we responsd with multiple entries for one breakpoint the VS Code UI gets out of date. Currently the VS code DAP doesn't handle one breakpoint with multiple locations. If this ever gets fixed we can modify our code.
Reviewers: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73665
Summary:
This patch creates a new subclass of the ABI class in order to abstract away the
mechanism in which we "augment" register information. This enables alternate
augmentation strategies to be introduced.
All existing ABI classes have been modified to inherit from RegInfoBasedABI, but
they will be refactored in subsequent patches.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: sdardis, nemanjai, kbarton, jrtc27, atanasyan, jsji, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74243
Summary:
The error message from the construct `assertTrue(a == b, "msg") ` are nearly always completely useless for actually debugging the issue.
This patch is just replacing this construct (and similar ones like `assertTrue(a != b, ...)` with the proper call to assertEqual or assertNotEquals.
This patch was mostly written by a shell script with some manual verification afterwards:
```
lang=python
import sys
def sanitize_line(line):
if line.strip().startswith("self.assertTrue(") and " == " in line:
line = line.replace("self.assertTrue(", "self.assertEquals(")
line = line.replace(" == ", ", ", 1)
if line.strip().startswith("self.assertTrue(") and " != " in line:
line = line.replace("self.assertTrue(", "self.assertNotEqual(")
line = line.replace(" != ", ", ", 1)
return line
for a in sys.argv[1:]:
with open(a, "r") as f:
lines = f.readlines()
with open(a, "w") as f:
for line in lines:
f.write(sanitize_line(line))
```
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74475
- reduce indentation by removing the defensive
GetID()!=INVALID_PROCESS_ID check -- this function is only called when
an attach or launch succeeds
- replace LLDB_LOGF with LLDB_LOG
Move the logic for initialization and termination for DynamicLoaderMacOS
into DynamicLoaderMacOSXDYLD so that there's one initializer for the
DynamicLoaderMacOSXDYLD plugin.
Move the logic for initialization and termination for
SymbolFileDWARFDebugMap into SymbolFileDWARF so that there's one
initializer for the SymbolFileDWARF plugin.
This fixes a UBSan error seen while debugging clang:
Member call on null pointer of type 'clang::TypeSourceInfo'
rdar://58783517
Differential Revision: https://reviews.llvm.org/D73808
Sema::RequireCompleteTypeImpl is supposed to have an assert that checks that the
SourceLocation that is passed in is always valid. It's currently commented out, but
as soon as this assert goes active, nearly every LLDB expression will start crashing as
we always pass in an invalid SourceLocation from the ASTResultSynthesizer.
This patch just passes in the valid SourceLocation of the expression (which is
the SourceLocation where the complete type is required) to prevent that from happening.
This patch enables the debug entry values feature.
- Remove the (CC1) experimental -femit-debug-entry-values option
- Enable it for x86, arm and aarch64 targets
- Resolve the test failures
- Leave the llc experimental option for targets that do not
support the CallSiteInfo yet
Differential Revision: https://reviews.llvm.org/D73534
Beside these two functions just being wrappers around GetTypeName they are also
just a leftover from migrating the CompilerType interface to ConstString.
They are all implementation details so let's keep them out of the interface.
Also makes this code more readable by keeping these small classes
not spread over header and source file.
It's not used by anyone. Also if something implements its own
completion it could just not call the method instead of having
a parameter that makes the function a no-op.
Summary: Moves lldbsuite tests to lldb/test/API.
This is a largely mechanical change, moved with the following steps:
```
rm lldb/test/API/testcases
mkdir -p lldb/test/API/{test_runner/test,tools/lldb-{server,vscode}}
mv lldb/packages/Python/lldbsuite/test/test_runner/test lldb/test/API/test_runner
for d in $(find lldb/packages/Python/lldbsuite/test/* -maxdepth 0 -type d | egrep -v "make|plugins|test_runner|tools"); do mv $d lldb/test/API; done
for d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-vscode -maxdepth 1 -mindepth 1 | grep -v ".py"); do mv $d lldb/test/API/tools/lldb-vscode; done
for d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-server -maxdepth 1 -mindepth 1 | egrep -v "gdbremote_testcase.py|lldbgdbserverutils.py|socket_packet_pump.py"); do mv $d lldb/test/API/tools/lldb-server; done
```
lldb/packages/Python/lldbsuite/__init__.py and lldb/test/API/lit.cfg.py were also updated with the new directory structure.
Reviewers: labath, JDevlieghere
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71151
This code seems wrong as the directory variable actually contains
the file name. It's also unreachable code as m_include_support_files
is hardcoded to false which is the condition for the surrounding 'if
statement'. Let's just remove all of this.
We now have a virtual-functions test and a multiple-inheritance test that
are testing the same functionality (and more) using the newer test functions which
we have in LLDB these days. These tests should also be less flaky and
less dependent on other unrelated LLDB functionality.
Summary:
The only use of this class was to implement the SharedCluster of ValueObjects.
However, the same functionality can be implemented using a regular
std::shared_ptr, and its little-known "sub-object pointer" feature, where the
pointer can point to one thing, but actually delete something else when it goes
out of scope.
This patch reimplements SharedCluster using this feature --
SharedClusterPointer::GetObject now returns a std::shared_pointer which points
to the ValueObject, but actually owns the whole cluster. The only change I
needed to make here is that now the SharedCluster object needs to be created
before the root ValueObject. This means that all private ValueObject
constructors get a ClusterManager argument, and their static Create functions do
the create-a-manager-and-pass-it-to-value-object dance.
Reviewers: teemperor, JDevlieghere, jingham
Subscribers: mgorny, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74153
This reimplements commit 6b2979c123 and updates
the tests to reflect the addition of the alternate symbol attribute.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
StringRef will call strlen on the C string which is inefficient (as ConstString already
knows the string lenght and so does StringRef). This patch replaces all those calls
with GetStringRef() which doesn't recompute the length.
This breaks macOS, because TARGET_OS_EMBEDDED is always defined. Thanks
to Jason Molenda for pointing this out.
Revert "Do not define AcceptPIDFromInferior when it will not be used"
This reverts commit d23c15a687.
This reverts commit 936d1427da.
Summary:
The return address validation in D71372 will fail if the memory permissions can't be determined. Many embedded stubs either don't implement the qMemoryRegionInfo packet, or don't have memory permissions at all.
Remove the return from the if clause that calls GetLoadAddressPermissions, so this call failing doesn't cause the step out to abort. Instead, assume that the memory permission check doesn't apply to this type of target.
Reviewers: labath, jingham, clayborg, mossberg
Reviewed By: labath, jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72513
Look up the -arch flags to pass to the mig invocation from an
optionally-defined MIG_ARCHS variable. We can't use CMAKE_OSX_ARCHS
because the {i,tv,watch}OS builds don't use this mechanism to achieve
fat builds (they build each slice separately & then lipo them together).
This supercedes the mig -arch/-isysroot fix from
510758dae2.
m_size can only be 1 or 0 and indicates if the optional has a value. Calling
it 'm_size', giving it a size_t data type and then also comparing indices against
'size' is very confusing. Let's just make this a bool.
D73303 was failing on Fedora Linux and so it was disabled by Skip the
AssertFrameRecognizer test for Linux.
I find no easy way how to find out if it gets recognized as
`__assert_fail` or `__GI___assert_fail` as during `Process` ctor
libc.so.6 is not yet loaded by the debuggee.
DWARF symbol `__GI___assert_fail` overrides the ELF symbol `__assert_fail`.
While external debug info (=DWARF) gets disabled for testsuite (D55859)
that sure does not apply for real world usage.
Differential Revision: https://reviews.llvm.org/D74252
Remove all beginning > from the sample commands as my accidental
copy-paste (multiple times...) will discard ./bin/llvm-lit which is
difficult to rebuild (I have to rm -rf and cmake it all again).
Differential Revision: https://reviews.llvm.org/D74296
This actually tests all the different situations in which we can call virtual
functions. This removes also all skipIfs as the first skipIf for Linux is
apparently fixed and the second skipIf was just failing due to the constructor
call (which should be its own test and not be tested here).
When I have symlinked builddir on Fedora 31 x86_64 I get:
FAIL: test_libraries_svr4_libs_present (TestGdbRemoteLibrariesSvr4Support.TestGdbRemoteLibrariesSvr4Support)
----------------------------------------------------------------------
...
File "lldb/packages/Python/lldbsuite/test/tools/lldb-server/libraries-svr4/TestGdbRemoteLibrariesSvr4Support.py", line 106, in
libraries_svr4_libs_present
self.assertIn(self.getBuildDir() + "/" + lib, libraries_svr4_names)
AssertionError:
'/home/jkratoch/redhat/llvm-monorepo-clangassertsymlink/lldb-test-build.noindex/tools/lldb-server/libraries-svr4/TestGdbRemoteLibrariesSvr4Support.test_libraries_svr4_libs_present/libsvr4lib_a.so' not found in ['/home/jkratoch/redhat/llvm-monorepo/lldb/packages/Python/lldbsuite/test/tools/lldb-server/libraries-svr4/linux-vdso.so.1', '/quad/home/jkratoch/redhat/llvm-monorepo-clangassertsymlink/lldb-test-build.noindex/tools/lldb-server/libraries-svr4/TestGdbRemoteLibrariesSvr4Support.test_libraries_svr4_libs_present/libsvr4lib_a.so', '/quad/home/jkratoch/redhat/llvm-monorepo-clangassertsymlink/lldb-test-build.noindex/tools/lldb-server/libraries-svr4/TestGdbRemoteLibrariesSvr4Support.test_libraries_svr4_libs_present/libsvr4lib_b".so', '/usr/lib64/libdl-2.30.so', '/usr/lib64/libstdc++.so.6.0.27', '/usr/lib64/libm-2.30.so', '/usr/lib64/libgcc_s-9-20190827.so.1', '/usr/lib64/libc-2.30.so', '/usr/lib64/ld-2.30.so']
Config=x86_64-/quad/home/jkratoch/redhat/llvm-monorepo-clangassertsymlink/bin/clang-11
----------------------------------------------------------------------
Differential Revision: https://reviews.llvm.org/D74295
This reverts commit cf1046c716.
Reverted: https://reviews.llvm.org/D74252
It fixed testsuite but broke real world functionality where is not used:
settings set symbols.enable-external-lookup false
Apparently Linux and Windows have the exact opposite behavior when it
comes to inline declarations of external functions. On Linux they're
considered to be part of the lldb_private namespace, while on Windows
they're considered to be part of the top level namespace. Somehow on
macOS, it doesn't really matter and both are fine...
At this point I don't know what to do, so I'm just adding the
LLDB_PLUGIN_DECLARE macros again as originally proposed in D74245.
Reid found a bug in removing Listeners from a BroadcasterManager:
https://reviews.llvm.org/D74010
The bug didn't affect the case where there was only one Listener
signed up for a BroadcasterManager, which was all the extant test
case tests. The driver also only uses one listener (the debugger)
for everything, so neither the test nor anything you do with lldb
command line would have triggered the bug.
This adds a couple more tests using more listeners, and adding and
removing them in a different way, which triggers a separate code path.
Summary: This option is not used anymore and has been replaced by the env var LLDBVSCODE_LOG.
Reviewers: clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74266
Summary:
Completion requests are causing some problems in the debugger, which is explained in the comment in the code.
I'm disabling it for now until we have time to do a good implementation of it.
Reviewers: clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74264
This is a step towards making the initialize and terminate calls be
generated by CMake, which in turn is towards making it possible to
disable plugins at configuration time.
Differential revision: https://reviews.llvm.org/D74245
Summary:
This creates a separate LLDB_TEST_SRC var to match the existing LLDB_TEST var. LLDB_TEST points to the test framework, LLDB_TEST_SRC points to the tests themselves.
The var points to the same place, but a future patch will move the tree + update var.
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: merge_guards_bot, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71150
D73303 was failing on Fedora Linux and so it was disabled by Skip the
AssertFrameRecognizer test for Linux.
On Fedora 30 x86_64 I have:
$ readelf -Ws /lib64/libc.so.6 |grep '^Symbol\|.*assert_fail'
Symbol table '.dynsym' contains 2362 entries:
630: 0000000000030520 70 FUNC GLOBAL DEFAULT 14 __assert_fail@@GLIBC_2.2.5
Symbol table '.symtab' contains 22711 entries:
922: 000000000002275a 15 FUNC LOCAL DEFAULT 14 __assert_fail_base.cold
18044: 0000000000030520 70 FUNC LOCAL DEFAULT 14 __GI___assert_fail
20081: 00000000000303a0 370 FUNC LOCAL DEFAULT 14 __assert_fail_base
21766: 0000000000030520 70 FUNC GLOBAL DEFAULT 14 __assert_fail
The patch should never expect __GI___assert_fail:
.symtab can be present or not but that should not change that
__assert_fail always wins - it is always present from .dynsym and it can
never be overriden by __GI___assert_fail as __GI___assert_fail has only
local binding. Global binding is preferred since D63540.
External debug info symbols do not matter since D55859 (and DWARF should
never be embedded in system libc.so.6).
Differential Revision: https://reviews.llvm.org/D74252
Summary:
There's a fair amount of code duplication between the different ABI plugins for
the same architecture (e.g. ABIMacOSX_arm & ABISysV_arm). Deduplicating this
code is not very easy at the moment because there is no good place where to put
the common code.
Instead of creating more plugins, this patch reduces their number by grouping
similar plugins into a single folder/plugin. This makes it easy to extract
common code to a (e.g.) base class, which can then live in the same folder.
The grouping is done based on the underlying llvm target for that architecture,
because the plugins already require this for their operation.
Reviewers: JDevlieghere, jasonmolenda, jfb
Subscribers: sdardis, nemanjai, mgorny, kristof.beyls, fedor.sergeev, kbarton, jrtc27, atanasyan, jsji, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74138
This patch skips the AssertFrameRecognizer test for Linux since it appears to
fail on certain distributions (AFAIK Fedora & ArchLinux).
The failure happen because the thread don't set the current frame to
the most relevant one. So the stopped location doesn't match with what
the test is expecting.
The test will be enabled again after I'll be able to reproduce the failure
on one of those platform and fix the issue.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Implement detection of ELF binary format, and support for i386 register
context on amd64 when a 32-bit executable is being debugged. This is
roughly based on the code from Linux.
Differential Revision: https://reviews.llvm.org/D73974
By clearing the recognizers before starting the test, we ensure that the
recognizers that get initialized when lldb starts won't alter the
expected results of this test (i.e. recognizer index).
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
One way to register a recognizer is to use RegularExpressionSP for the
module and symbol.
In order to match a symbol regardless of the module, the recognizer can
be registered with a nullptr for the module. However, this cause the
frame recognizer list command to crash because it calls
RegularExpression::GetText without checking if the shared pointer is valid.
This patch adds checks for the symbol and module RegularExpressionSP.
Differential Revision: https://reviews.llvm.org/D74212
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
To my knowledge we don't actually use or need these rules. And if we need them then
there is probably a better way to implement this than having all these random regexes.
Reviewers: labath, JDevlieghere
Reviewed By: labath, JDevlieghere
Subscribers: jingham, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74126
Summary:
In D66791 I've introduced this [[ https://cmake.org/cmake/help/latest/module/CMakeDependentOption.html | `CMakeDependentOption` ]] but in
D71306 @JDevlieghere has changed the way optional dependencies
are handled in LLDB. Today there's no occurence of
`cmake_dependent_option` inside the lldb source tree.
That's why this include can be removed.
Reviewers: JDevlieghere, labath
Reviewed By: labath
Subscribers: labath, mgorny, lldb-commits, JDevlieghere
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74160
EXCLUDE_FROM_ALL means something else for add_lit_testsuite as it does
for something like add_executable. Distinguish between the two by
renaming the variable and making it an argument to add_lit_testsuite.
Differential revision: https://reviews.llvm.org/D74168
Refactore GetStopReasonExtendedBacktraces so that the reproducer macro
is passed an instrumented copy constructor rather than the constructor
taking a ThreadCollectionSP, which is not instrumented.
Summary: Currently, lldb-repro is placed in the wrong location for multi-configuration generators. For example, in the case of VS, it is placed in a directory $(Configuration) instead of in each of Debug, Release, etc.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: mgorny, lldb-commits, asmith
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74148
Due to a c++ quirk, these are found through ADL only when a function with that
name is found through regular lookup. We have one such function in SharingPtr.h,
but I am trying to remove it.
Summary:
When the generator used for CMake is a multi-configuration generator (such as VS), the arguments passed to dotest are not currently configured correctly. There are a couple of issues:
1) The per-configuration files are all generated for the same configuration since the for loop overwrites the properties
2) Not all of the parameters are configured in the lit cfg, so they end up with %(build_mode)s as configuration and they point to non-existent paths
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: mgorny, lldb-commits, asmith
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74093
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
For the methods taking a char* and a length that have a custom replayer,
ignore the incoming string in the instrumentation macro. This prevents
potentially reading garbage and blowing up the SB API log.
Summary:
This is a preparatory patch to re-enable DWP support in lldb (we already
have code claiming to do that, but it has been completely broken for a
while now).
The idea of the new approach is to make the SymbolFileDWARFDwo class
handle both dwo and dwo files, similar to how llvm uses one DWARFContext
to handle the two.
The first step is to remove the assumption that a SymbolFileDWARFDwo
holds just a single compile unit, i.e. the GetBaseCompileUnit method.
This requires changing the way how we reach the skeleton compile unit
(and the lldb_private::CompileUnit) from a dwo unit, which was
previously done via GetSymbolFile()->GetBaseCompileUnit() (and some
virtual dispatch).
The new approach reuses the "user data" mechanism of DWARFUnits, which
was used to link dwarf units (both skeleton and split) to their
lldb_private counterparts. Now, this is done only for non-dwo units, and
instead of that, the dwo units holds a pointer to the relevant skeleton
unit.
Reviewers: JDevlieghere, aprantl, clayborg
Reviewed By: JDevlieghere, clayborg
Subscribers: arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73781
Raphael Isemann