This is very similar to D85968, only more elusive to since we were not
adding the typedef type to the relevant DeclContext until D86140, which
meant that the DeclContext was populated (and the relevant assertion
hit) only after importing the type into the expression ast in a
particular way.
I haven't checked whether this situation can be hit in the gmodules
case, but my money is on "yes".
Differential Revision: https://reviews.llvm.org/D86216
Parsing DWARFv5 debug_loclist offsets when a CU is parsed is weighing
down memory usage of symbolizers that don't need to parse this data at
all. There's not much benefit to caching these anyway - since they are
O(1) lookup and reading once you know where the offset list starts (and
can do bounds checking with the offset list size too).
In general, I think it might be time to start paying down some of the
technical debt of loc/loclist/range/rnglist parsing to try to unify it a
bit more.
eg:
* Currently DWARFUnit has: RangeSection, RangeSectionBase, LocSection,
LocSectionBase, LocTable, RngListTable, LoclistTableHeader (be nice if
these were all wrapped up in two variables - one for loclists, one for
rnglists)
* rnglists and loclists are handled differently (see:
LoclistTableHeader, but no RnglistTableHeader)
* maybe all these types could be less stateful - lazily parse what they
need to, even reparsing rather than caching because it doesn't seem
too expensive, for instance. (though admittedly so long as it's
constantcost/overead per compilatiton that's probably adequate)
* Maybe implementing and using a DWARFDataExtractor that can be
sub-ranged (so we could slice it up to just the single contribution) -
though maybe that's not so useful because loc/ranges need to refer to
it by absolute, not contribution-relative mechanisms
Differential Revision: https://reviews.llvm.org/D86110
This patch is a big sed to rename the following variables:
s/PYTHON_LIBRARIES/Python3_LIBRARIES/g
s/PYTHON_INCLUDE_DIRS/Python3_INCLUDE_DIRS/g
s/PYTHON_EXECUTABLE/Python3_EXECUTABLE/g
s/PYTHON_RPATH/Python3_RPATH/g
I've also renamed the CMake module to better express its purpose and for
consistency with FindLuaAndSwig.
Differential revision: https://reviews.llvm.org/D85976
With -flimit-debug-info, we can run into cases when we only have a class
as a declaration, but we do have a definition of a nested class. In this
case, clang will hit an assertion when adding a member to an incomplete
type (but only if it's adding a c++ class, and not C struct).
It turns out we already had code to handle a similar situation arising
in the -gmodules scenario. This extends the code to handle
-flimit-debug-info as well, and reorganizes bits of other code handling
completion of types to move functions doing similar things closer
together.
Differential Revision: https://reviews.llvm.org/D85968
When bit-field data was stored in a Scalar in ValueObjectChild during UpdateValue()
it was extracting the bit-field value. Later on in lldb_private::DumpDataExtractor(…)
we were again attempting to extract the bit-field. Which would then not obtain the
correct value. This will remove the extra extraction in UpdateValue().
We hit this specific case when values are passed in registers, which we could only
reproduce in an optimized build.
Differential Revision: https://reviews.llvm.org/D85376
When loading a PE/COFF target, the associated PDB file often wasn't
found. The executable module contains a path for the associated PDB
file, but people often debug from a different directory than the one
their build system uses. (This is especially common in post-mortem
and cross platform debugging.)
Suppose the COFF executable being debugged is `~/proj/foo.exe`, but
it was built elsewhere and refers to `D:\remote\build\env\foobar.pdb`,
LLDB wouldn't find it.
With this change, if no file exists at the PDB path, LLDB will look
in the executable directory for a PDB file that matches the name of
the one it expected (e.g., `~/proj/foobar.pdb`). If found, the PDB
is subject to the same matching criteria (GUIDs and age) as would
have been used had it been in the original location.
This same-directory-as-the-binary rule is commonly used by debuggers
on Windows.
Differential Review: https://reviews.llvm.org/D84815
GNU ld allows sections after a non-SHF_ALLOC section to be covered by PT_LOAD
(PR37607) and assigns addresses to non-SHF_ALLOC output sections (similar to
SHF_ALLOC NOBITS sections. The location counter is not advanced).
This patch tries to fix PR37607 (remove a special case in
`Writer<ELFT>::createPhdrs`). To make the created PT_LOAD meaningful, we cannot
reset dot to 0 for a middle non-SHF_ALLOC output section. This results in
removal of two special cases in LinkerScript::assignOffsets. Non-SHF_ALLOC
non-orphan sections can have non-zero addresses like in GNU ld.
The zero address rule for non-SHF_ALLOC sections is weakened to apply to orphan
only. This results in a special case in createSection and findOrphanPos, respectively.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D85100
Add an option that allows the user to decide to not make the inferior is
responsible for its own TCC permissions. If you don't make the inferior
responsible, it inherits the permissions of its parent. The motivation
is the scenario of running the LLDB test suite from an external hard
drive. If the inferior is responsible, every test needs to be granted
access to the external volume. When the permissions are inherited,
approval needs to be granted only once.
Differential revision: https://reviews.llvm.org/D85237
I have made the DW_FORM_ref4 relative. One could also use relocated
DW_FORM_ref_addr instead.
Tested with:
echo 'void f(){}'|clang -o 1.o -c -Wall -g -x c -;./bin/clang -o 1 1.o ../llvm-monorepo/lldb/test/Shell/SymbolFile/DWARF/DW_TAG_GNU_call_site-DW_AT_low_pc.s;./bin/lldb --no-lldbinit ./1 -o r -o 'p p' -o exit
Summary:
This effectively reverts r188124, which added code to handle
(DW_AT_)declarations of structures with some kinds of children as
definitions. The commit message claims this is a workaround for some
kind of debug info produced by gcc. However, it does not go into
specifics, so it's hard to reproduce or verify that this is indeed still a
problem.
Having this code is definitely a problem though, because it mistakenly
declares incomplete dwarf declarations to be complete. Both clang (with
-flimit-debug-info) and gcc (by default) generate DW_AT_declarations of
structs with children. This happens when full debug info for a class is
not emitted in a given compile unit (e.g. because of vtable homing), but
the class has inline methods which are used in the given compile unit.
In that case, the compilers emit a DW_AT_declaration of a class, but
add a DW_TAG_subprogram child to it to describe the inlined instance of
the method.
Even though the class tag has some children, it definitely does not
contain enough information to construct a full class definition (most
notably, it lacks any members). Keeping the class as incomplete allows
us to search for a real definition in other modules, helping the
-flimit-debug-info flow. And in case the definition is not found we can
display a error message saying that, instead of just showing an empty
struct.
Reviewers: clayborg, aprantl, JDevlieghere, shafik
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83302
RecordInterestingDirectory was added to collect dSYM bundles and their
content. For the current working directory we only want the directory to
be part of the VFS, not necessarily its contents. This patch renames the
current method to RecordInterestingDirectoryRecursively and adds a new
one that's not recursive.
Summary:
With D81784, lld has started debug info resolving relocations to
garbage-collected symbols as -1 (instead of relocation addend). For an
unaware consumer this generated sequences which seemingly wrap the
address space -- their first entry was 0xfffff, but all other entries
were low numbers.
Lldb stores line sequences concatenated into one large vector, sorted by
the first entry, and searched with std::lower_bound. This resulted in
the low-value entries being placed at the end of the vector, which
utterly confused the lower_bound algorithm, and caused it to not find a
match. (Previously, these sequences would be at the start of the vector,
and normally would contain addresses that are far smaller than any real
address we want to look up, so std::lower_bound was fine.)
This patch makes lldb ignore these kinds of sequences completely. It
does that by changing the construction algorithm from iterating over the
rows (as parsed by llvm), to iterating over the sequences. This is
important because the llvm parsed performs validity checks when
constructing the sequence array, whereas the row array contains raw
data.
Reviewers: JDevlieghere, MaskRay
Differential Revision: https://reviews.llvm.org/D83957
Summary:
Currently expect_expr will not run the expression if no target is selected. This
patch changes this behavior so that expect_expr will instead fall back to the
dummy target similar to what the `expression` command is doing. This way we
don't have to compile an empty executable to be able to use `expect_expr` (which
is a waste of resources for tests that just test generic type system features).
As a test I modernized the TestTypeOfDeclTypeExpr into a Python test +
expect_expr (as it relied on the dummy target fallback of the expression
command).
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D83388
Summary:
-debug-info-kind=constructor reduces the amount of class debug info that
is emitted; this patch switches to using this as the default.
Constructor homing emits the complete type info for a class only when the
constructor is emitted, so it is expected that there will be some classes that
are not defined in the debug info anymore because they are never constructed,
and we shouldn't need debug info for these classes.
I compared the PDB files for clang, and there are 273 class types that are defined with `=limited`
but not with `=constructor` (out of ~60,000 total class types).
We've looked at a number of the types that are no longer defined with =constructor. The vast
majority of cases are something like class A is used as a parameter in a member function of
some other class B, which is emitted. But the function that uses class A is never called, and class A
is never constructed, and therefore isn't emitted in the debug info.
Bug: https://bugs.llvm.org/show_bug.cgi?id=46537
Subscribers: aprantl, cfe-commits, lldb-commits
Tags: #clang, #lldb
Differential Revision: https://reviews.llvm.org/D79147
There are bugs where you don't want the signal handler to trigger, most
notably when that will cause another crash. Examples of this are lldb
running out of memory or a bug in the reproducer generation code. This
adds an escape hatch trough a (developer oriented) flag to not install
the signal handler.
rdar://problem/65149595
Differential revision: https://reviews.llvm.org/D83496
This is a preparatory rename of the developer facing reproducer flags.
reproducer-skip-version-check -> reproducer-no-version-check
reproducer-auto-generate -> reproducer-generate-on-quit
With -flimit-debug-info, we can have a definition of a class, but no
definition for some of its members. This extends the same logic we were
using for incomplete base classes to cover incomplete members too.
Test forward-declarations.s is removed as it is no longer applicable --
we don't warn anymore when encountering incomplete members as they could
be completed elsewhere. New checks added to TestLimitDebugInfo cover the
handling of incomplete members more thoroughly.
This complements the existing TestLimitDebugInfo.py, which tests this
scenario more comprehensively, but is not able to run on all hosts.
Specifically, it's hard to trigger this code from windows because clang
tries hard to ensure that debug info for types marked with
__declspec(dllexport) is emitted even under -flimit-debug-info (and
dllexport is needed to use a type across shared libraries).
This assembly-based test serves two purposes:
- it tests that -flimit-debug-info code path works for windows binaries
(even though the aforementioned feature means its less likely to be
used there)
- it gives basic test coverage for the -flimit-debug-info handling code
when running the test suite on windows hosts.
On macOS 11, system libraries which are part of the shared cache
are not present on the filesystem anymore. This causes issues
with build.py, because it fails to link binaries with libSystem
or libc++.
The real issue is that build.py was not passing an SDK to the
compiler. The script accepts an argument for the SDK, but it
is currently unused. This patch just threads the SDK through
to the compile and link steps and this fixes a bunch of Shell
test failures on very recent macOS builds.
The `frame recognizer` command only exists when Python scripting is
enabled. Therefore the test should be made conditional on Python.
Without it, the test fails with "'frame recognizer' is not a known
command."
The test fails on Darwin because a different Asynchronous UnwindPlan is
chosen:
Asynchronous (not restricted to call-sites) UnwindPlan is 'assembly
insn profiling'`
instead of what the test expects:
Asynchronous (not restricted to call-sites) UnwindPlan is 'eh_frame
CFI'
Summary:
This fixes a bug in the logic for choosing the unwind plan. Based on the
comment in UnwindAssembly-x86, the intention was that a plan which
describes the function epilogue correctly does not need to be augmented
(and it should be used directly). However, the way this was implemented
(by returning false) meant that the higher level code
(FuncUnwinders::GetEHFrameAugmentedUnwindPlan) interpreted this as a
failure to produce _any_ plan and proceeded with other fallback options.
The fallback usually chosed for "asynchronous" plans was the
"instruction emulation" plan, which tended to fall over on certain
functions with multiple epilogues (that's a separate bug).
This patch simply changes the function to return true, which signals the
caller that the unmodified plan is ready to be used.
The attached test case demonstrates the case where we would previously
fall back to the instruction emulation plan, and unwind incorrectly --
the test asserts that the "augmented" eh_frame plan is used, and that
the unwind is correct.
Reviewers: jasonmolenda, jankratochvil
Subscribers: davide, echristo, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D82378
Summary:
When evaluating an expression referencing a constexpr static member variable, an
error is issued because the PDB does not specify a symbol with an address that
can be relocated against.
Rather than attempt to resolve the variable's value within the IR execution, the
values of all constants can be looked up and incorporated into the AST of the
record type as a literal, mirroring the original compiler AST.
This change applies to DIA and native PDB loaders.
Patch By: jackoalan
Reviewers: aleksandr.urakov, jasonmolenda, zturner, jdoerfert, teemperor
Reviewed By: aleksandr.urakov
Subscribers: sstefan1, lldb-commits, llvm-commits, #lldb
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D82160
Add support for changing the stdout and stderr file in Lua's I/O library
and hook it up with the debugger's output and error file respectively
for the interactive Lua interpreter.
https://reviews.llvm.org/D82273
Add a way to quit the interactive script interpreter from a shell tests.
Currently, the only way (that I know) to exit the interactive Lua
interpreter is to send a EOF with CTRL-D. I noticed that the embedded
Python script interpreter accepts quit (while the regular python
interpreter doesn't). I've added a special case to the Lua interpreter
to do the same.
Differential revision: https://reviews.llvm.org/D82272
Executing commands below will get you bombarded by a wall of Python
command prompts (>>> ).
$ echo 'foo' | ./bin/lldb -o script
$ cat /tmp/script
script
print("foo")
$ lldb --source /tmp/script
The issue is that our custom input reader doesn't handle EOF. According
to the Python documentation, file.readline always includes a trailing
newline character unless the file ends with an incomplete line. An empty
string signals EOF. This patch raises an EOFError when that happens.
[1] https://docs.python.org/2/library/stdtypes.html#file.readline
Differential revision: https://reviews.llvm.org/D81898
Color the error: and warning: part of the CommandReturnObject output,
similar to how an error is printed from the driver when colors are
enabled.
Differential revision: https://reviews.llvm.org/D81058
D80519 <https://reviews.llvm.org/D80519>
added support for `DW_TAG_GNU_call_site` but
Bug 45886 <https://bugs.llvm.org/show_bug.cgi?id=45886>
found one case did not work.
There is:
0x000000b1: DW_TAG_GNU_call_site
DW_AT_low_pc (0x000000000040111e)
DW_AT_abstract_origin (0x000000cc "a")
...
0x000000cc: DW_TAG_subprogram
DW_AT_name ("a")
DW_AT_prototyped (true)
DW_AT_low_pc (0x0000000000401109)
^^^^^^^^^^^^ - here it did overwrite the 'low_pc' variable containing value 0x40111e we wanted
DW_AT_high_pc (0x0000000000401114)
DW_AT_frame_base (DW_OP_call_frame_cfa)
DW_AT_GNU_all_call_sites (true)
DW_TAG_GNU_call_site attributes order as produced by GCC:
0x000000b1: DW_TAG_GNU_call_site
DW_AT_low_pc (0x000000000040111e)
DW_AT_abstract_origin (0x000000cc "a")
clang produces the attributes in opposite order:
0x00000064: DW_TAG_GNU_call_site
DW_AT_abstract_origin (0x0000002a "a")
DW_AT_low_pc (0x0000000000401146)
Differential Revision: https://reviews.llvm.org/D81334
Previously, we were simply ignoring them and continuing the evaluation.
This behavior does not seem useful, because the resulting value will
most likely be completely bogus.
Several SBAddress properties use the lldb.target or lldb.process
convenience variables which are only set under the interactive script
interpreter. Unfortunately, users have been using these properties in
Python script and commands. This patch raises a Python exception to
force users to use GetLoadAddress instead.
Differential revision: https://reviews.llvm.org/D80848
This adds a new target `check-lldb-reproducers` that replaces the old
`check-lldb-repro`. The latter would only run the shell tests, while
`check-lldb-reproducers` includes the API tests as well. The new target
will be used on GreenDragon.
It's still possible to run just the shell tests with reproducers,
although now that requires crafting the lit invocation yourself. The
parameters haven't changed and are the shame for the API and shell
tests:
--param lldb-run-with-repro=capture
--param lldb-run-with-repro=replay
This patch also updates the reproducer documentation.
Summary:
For ObjCInterfaceDecls, LLDB iterates over the `methods` of the interface in FindExternalVisibleDeclsByName
since commit ef423a3ba5 .
However, when LLDB calls `oid->methods()` in that function, Clang will pull in all declarations in the current
DeclContext from the current ExternalASTSource (which is again, `ClangExternalASTSourceCallbacks`). The
reason for that is that `methods()` is just a wrapper for `decls()` which is supposed to provide a list of *all*
(both currently loaded and external) decls in the DeclContext.
However, `ClangExternalASTSourceCallbacks::FindExternalLexicalDecls` doesn't implement support for ObjCInterfaceDecl,
so we don't actually add any declarations and just mark the ObjCInterfaceDecl as having no ExternalLexicalStorage.
As LLDB uses the ExternalLexicalStorage to see if it can complete a type with the ExternalASTSource, this causes
that LLDB thinks our class can't be completed any further by the ExternalASTSource
and will from on no longer make any CompleteType/FindExternalLexicalDecls calls to that decl. This essentially
renders those types unusable in the expression parser as they will always be considered incomplete.
This patch just changes the call to `methods` (which is just a `decls()` wrapper), to some ad-hoc `noload_methods`
call which is wrapping `noload_decls()`. `noload_decls()` won't trigger any calls to the ExternalASTSource, so
this prevents that ExternalLexicalStorage will be set to false.
The test for this is just adding a method to an ObjC interface. Before this patch, this unset the ExternalLexicalStorage
flag and put the interface into the state described above.
In a normal user session this situation was triggered by setting a breakpoint in a method of some ObjC class. This
caused LLDB to create the MethodDecl for that specific method and put it into the the ObjCInterfaceDecl.
Also `ObjCLanguageRuntime::LookupInCompleteClassCache` needs to be unable to resolve the type do
an actual definition when the breakpoint is set (I'm not sure how exactly this can happen, but we just
found no Type instance that had the `TypePayloadClang::IsCompleteObjCClass` flag set in its payload in
the situation where this happens. This however doesn't seem to be a regression as logic wasn't changed
from what I can see).
The module-ownership.mm test had to be changed as the only reason why the ObjC interface in that test had
it's ExternalLexicalStorage flag set to false was because of this unintended side effect. What actually happens
in the test is that ExternalLexicalStorage is first set to false in `DWARFASTParserClang::CompleteTypeFromDWARF`
when we try to complete the `SomeClass` interface, but is then the flag is set back to true once we add
the last ivar of `SomeClass` (see `SetMemberOwningModule` in `TypeSystemClang.cpp` which is called
when we add the ivar). I'll fix the code for that in a follow-up patch.
I think some of the code here needs some rethinking. LLDB and Clang shouldn't infer anything about the ExternalASTSource
and its ability to complete the current type form the `ExternalLexicalStorage` flag. We probably should
also actually provide any declarations when we get asked for the lexical decls of an ObjCInterfaceDecl. But both of those
changes are bigger (and most likely would cause us to eagerly complete more types), so those will be follow up patches
and this patch just brings us back to the state before commit ef423a3ba5 .
Fixes rdar://63584164
Reviewers: aprantl, friss, shafik
Reviewed By: aprantl, shafik
Subscribers: arphaman, abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D80556
The llvm DWARFExpression dump is nearly identical, but better -- for
example it does print a spurious space after zero-argument expressions.
Some parts of our code (variable locations) have been already switched
to llvm-based expression dumping. This switches the remainder: unwind
plans and some unit tests.
This patchs adds an optional warning that is printed when stopped at a
frame that was compiled in a source language that LLDB has no plugin
for.
The motivational use-case is debugging Swift code on Linux. When the
user accidentally invokes the system LLDB that was built without the
Swift plugin, it is very much non-obvious why debugging doesnt
work. This warning makes it easy to figure out what went wrong.
<rdar://problem/56986569>
Print a little snippet before exiting when passed unrecognized
arguments. The goal is twofold:
- Point users to lldb --help.
- Make it clear that we exited the debugger.
There appears to be consensus in D80165 that this is the desired
behavior and I personally agree.
Differential revision: https://reviews.llvm.org/D80226
Before the transition to libOption it was possible to specify arguments
for the inferior without -- as long as they didn't start with a dash.
For example, the following invocations should all behave the same:
$ lldb inferior inferior-arg
$ lldb inferior -- inferior-arg
$ lldb -- inferior inferior-arg
This patch fixes that behavior, documents it and adds a test to cover
the different combinations.
Differential revision: https://reviews.llvm.org/D80165
This reverts commit 525a591f0f.
Fixed an issue with pointers to members based on typedefs. In this case,
LLVM would emit a second UDT. I fixed it by not passing the class type
to getTypeIndex when the base type is not a function type. lowerType
only uses the class type for direct function types. This suggests if we
have a PMF with a function typedef, there may be an issue, but that can
be solved separately.
> Before this patch, S_[L|G][THREAD32|DATA32] records were emitted with a simple name, not the fully qualified name (namespace + class scope).
>
> Differential Revision: https://reviews.llvm.org/D79447
This causes asserts in Chromium builds:
CodeViewDebug.cpp:2997: void llvm::CodeViewDebug::emitDebugInfoForUDTs(const std::vector<std::pair<std::string, const DIType *>> &):
Assertion `OriginalSize == UDTs.size()' failed.
I will follow up on the Phabricator issue.
Before this patch, S_[L|G][THREAD32|DATA32] records were emitted with a simple name, not the fully qualified name (namespace + class scope).
Differential Revision: https://reviews.llvm.org/D79447
This recommits f665e80c02 which was reverted in 1cbd1b8f69 for breaking
TestFoundationDisassembly.py. The fix is to use --force in the test to avoid
bailing out on large functions.
I have also doubled the large function limit to 8000 bytes (~~ 2000 insns), as
the foundation library contains a lot of large-ish functions. The intent of this
feature is to prevent accidental disassembling of enormous (multi-megabyte)
"functions", not to get in people's way.
The original commit message follows:
If we have a binary without symbol information (and without
LC_FUNCTION_STARTS, if on a mac), then we have to resort to using
heuristics to determine the function boundaries. However, these don't
always work, and so we can easily end up thinking we have functions
which are several megabytes in size. Attempting to (accidentally)
disassemble these can take a very long time spam the terminal with
thousands of lines of disassembly.
This patch works around that problem by adding a sanity check to the
disassemble command. If we are about to disassemble a function which is
larger than a certain threshold, we will refuse to disassemble such a
function unless the user explicitly specifies the number of instructions
to disassemble, uses start/stop addresses for disassembly, or passes the
(new) --force argument.
The threshold is currently fairly aggressive (4000 bytes ~~ 1000
instructions). If needed, we can increase it, or even make it
configurable.
Differential Revision: https://reviews.llvm.org/D79789
These test don't execute the binaries they build, and so they don't need
to build for the host. By hardcoding the target, we don't have do xfail
or skip them for targets which don't have the appropriate support in
clang(-cl).
Summary:
If we have a binary without symbol information (and without
LC_FUNCTION_STARTS, if on a mac), then we have to resort to using
heuristics to determine the function boundaries. However, these don't
always work, and so we can easily end up thinking we have functions
which are several megabytes in size. Attempting to (accidentally)
disassemble these can take a very long time spam the terminal with
thousands of lines of disassembly.
This patch works around that problem by adding a sanity check to the
disassemble command. If we are about to disassemble a function which is
larger than a certain threshold, we will refuse to disassemble such a
function unless the user explicitly specifies the number of instructions
to disassemble, uses start/stop addresses for disassembly, or passes the
(new) --force argument.
The threshold is currently fairly aggressive (4000 bytes ~~ 1000
instructions). If needed, we can increase it, or even make it
configurable.
Differential Revision: https://reviews.llvm.org/D79789
Summary:
The D programming language has 'char', 'wchar', and 'dchar' as base types,
which are defined as UTF-8, UTF-16, and UTF-32, respectively.
It also has type constructors (e.g. 'const' and 'immutable'),
that leads to D compilers emitting DW_TAG_base_type with DW_ATE_UTF
and name 'char', 'immutable(wchar)', 'const(char)', etc...
Before this patch, DW_ATE_UTF would only recognize types that
followed the C/C++ naming, and emit an error message for the rest, e.g.:
```
error: need to add support for DW_TAG_base_type 'immutable(char)'
encoded with DW_ATE = 0x10, bit_size = 8
```
The code was changed to check the byte size first,
then fall back to the old name-based check.
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79559
This patch marks following tests as xfail for arm-linux target.
lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
lldb/test/API/python_api/thread/TestThreadAPI.py
lldb/test/Shell/Recognizer/assert.test
Bugs have been filed for all of them for the corresponding failing
component.
This patch fixes minidebuginfo-set-and-hit-breakpoint.test for arm-linux
targets. 32-bit elf executables use .rel.dyn and 64-bit uses .rela.dyn for
relocation entries for dynamic symbols.
While debugging why TestProcessList.py failed during passive replay, I
remembered that we don't serialize the arguments for ProcessInfo. This
is necessary to make the test pass and to make platform process list -v
behave the same during capture and replay.
Differential revision: https://reviews.llvm.org/D79646
Following test cases need minor adjustment in order to accomodate xfail
decorator:
lldb/test/Shell/SymbolFile/NativePDB/break-by-line.cpp
lldb/test/Shell/SymbolFile/NativePDB/source-list.cpp
The relevant output FileCheck is scanning in this test is as follows:
CXXRecordDecl 0x7f96cf8239c8 <<invalid sloc>> <invalid sloc> imported in A.B <undeserialized declarations> struct definition
<<DefinitionData boilerplate>>
`-FieldDecl 0x7f96cf823b90 <<invalid sloc>> <invalid sloc> imported in A.B anon_field_b 'int'
(anonymous struct)
CXXRecordDecl 0x7f96cf823be8 <<invalid sloc>> <invalid sloc> imported in A.B struct
Before 710fa2c4ee this test was passing by
accident as it had a -DAG suffix in the checks changed by this patch,
causing FileCheck to first match the last line of the output above
(instead of the first one), and then finding the FieldDecl above.
When I removed the -DAG suffix, FileCheck actually enforced the ordering
and started failing as the FieldDecl comes before the CXXRecordDecl match
we get.
This patch fixes the CXXRecordDecl check to find the first line of the output
above which caused FileCheck to also find the FieldDecl that follows. Also
gives the FieldDecl a more unique name to make name collisions less likely.
This test was generating the following false-positive warning when being compiled:
warning: class 'SomeClass' defined without specifying a base class [-Wobjc-root-class]
The current test is checking both the anonymous structs and the template
specializations in one FileCheck run, but the anonymous struct line can
partially match the AST dump of a template specialization, causing that
FileCheck won't match that same line later against the template specialization
check and incorrectly fails on that check. This only happens when the
template specialization node somehow ends up before the anonymous struct node.
This patch just puts the checks for the anonymous structs in their own FileCheck
run to prevent them from partially matching any other record decl.
Fixes rdar://62997926
We have the option to stop running commands in batch mode when an error
occurs. When that happens we should exit the driver with a non-zero exit
code.
Differential revision: https://reviews.llvm.org/D78825
Summary:
This was originally commented out as it broke the data-formatter-stl/libcxx/
tests. However this was fixed by commit ef423a3ba5
(Add Objective-C property accessors loaded from Clang module DWARF to lookup)
which sets the HasExternalVisibleStorage flag for the template specializations.
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D79168
The cause of this crash is relatively simple -- we are using a
SymbolFileDWARFDwo to parse a (skeleton) dwarf unit. This cause the
CompileUnit to be created with the wrong ID, which later triggers an
assertion in SymbolFile::SetCompileUnitAtIndex. The fix is also simple
-- ensure we use the right symbol file for parsing.
However, a fairly elaborate setup is needed trigger this bug, because
ParseCompileUnit is normally called very early on (and with the right
symbol file object) during the process of accessing a compile unit.
The only way this can be triggered is if the DWARF unit is
"accidentally" pulled into scope during expression evaluation
This can happen if the "this" object used for the context of an
expression is in a namespace, and that namespace is also present in
other compile units
The included test recreates this setup.
This patch fixes a bug when synthesizing an ObjC property from
-gmodules debug info. Because the method declaration that is injected
via the non-modular property implementation is not added to the
ObjCInterfaceDecl's lookup pointer, a second copy of the accessor
would be generated when processing the ObjCPropertyDecl. This can be
avoided by finding the existing method decl in
ClangExternalASTSourceCallbacks::FindExternalVisibleDeclsByName() and
adding it to the LookupPtr.
Differential Revision: https://reviews.llvm.org/D78333
Summary:
The code in DWARFCompileUnit::BuildAddressRangeTable tries hard to avoid
relying on DW_AT_low/high_pc for compile unit range information, and
this logic is a big cause of llvm/lldb divergence in the lowest layers
of dwarf parsing code.
The implicit assumption in that code is that this information (as opposed to
DW_AT_ranges) is unreliable. However, I have not been able to verify
that assumption. It is definitely not true for all present-day
compilers (gcc, clang, icc), and it was also not the case for the
historic compilers that I have been able to get a hold of (thanks Matt
Godbolt).
All compiler included in my research either produced correct
DW_AT_ranges or .debug_aranges entries, or they produced no DW_AT_hi/lo
pc at all. The detailed findings are:
- gcc >= 4.4: produces DW_AT_ranges and .debug_aranges
- 4.1 <= gcc < 4.4: no DW_AT_ranges, no DW_AT_high_pc, .debug_aranges
present. The upper version range here is uncertain as godbolt.org does
not have intermediate versions.
- gcc < 4.1: no versions on godbolt.org
- clang >= 3.5: produces DW_AT_ranges, and (optionally) .debug_aranges
- 3.4 <= clang < 3.5: no DW_AT_ranges, no DW_AT_high_pc, .debug_aranges
present.
- clang <= 3.3: no DW_AT_ranges, no DW_AT_high_pc, no .debug_aranges
- icc >= 16.0.1: produces DW_AT_ranges
- icc < 16.0.1: no functional versions on godbolt.org (some are present
but fail to compile)
Based on this analysis, I believe it is safe to start trusting
DW_AT_low/high_pc information in dwarf as well as remove the code for
manually reconstructing range information by traversing the DIE
structure, and just keep the line table fallback. The only compilers
where this will change behavior are pre-3.4 clangs, which are almost 7
years old now. However, the functionality should remain unchanged
because we will be able to reconstruct this information from the line
table, which seems to be needed for some line-tables-only scenarios
anyway (haven't researched this too much, but at least some compilers
seem to emit DW_AT_ranges even in these situations).
In addition, benchmarks showed that for these compilers computing the
ranges via line tables is noticably faster than doing so via the DIE
tree.
Other advantages include simplifying the code base, removing some
untested code (the only test changes are recent tests with overly
reduced synthetic dwarf), and increasing llvm convergence.
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78489
This patch threads an lldb::DescriptionLevel through the typesystem to
allow dumping the full Clang AST (level=verbose) of any lldb::Type in
addition to the human-readable source description (default
level=full). This type dumping interface is currently not exposed
through the SBAPI.
The application is to let lldb-test dump the clang AST of search
results. I need this to test lazy type completion of clang types in
subsequent patches.
Differential Revision: https://reviews.llvm.org/D78329
Originally committed as 416fa7720e
Reverted (due to buildbot failure - breaking lldb) in 7a45aeacf3.
I still can't seem to build lldb locally, but Pavel Labath has kindly
provided a potential fix to preserve the old behavior in lldb by
registering a simple recoverable error handler there that prints to the
desired stream in lldb, rather than stderr.
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
1;95;0csets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
This reapplies the previously reverted commit, but without support for
ClassTemplateSpecializations, which I'm going to look into separately.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
sets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
The FileCollector in LLDB collects every files that's used during a
debug session when capture is enabled. This ensures that the reproducer
only contains the files necessary to reproduce. This approach is not a
good fit for the dSYM bundle, which is a directory on disk, but should
be treated as a single unit.
On macOS LLDB have automatically find the matching dSYM for a binary by
its UUID. Having a incomplete dSYM in a reproducer can break debugging
even when reproducers are disabled.
This patch adds a was to specify a directory of interest to the
reproducers. It is called from SymbolVendorMacOSX with the path of the
dSYMs used by LLDB.
Differential revision: https://reviews.llvm.org/D76672
The FileCollector in LLDB collects every files that's used during a
debug session when capture is enabled. This ensures that the reproducer
only contains the files necessary to reproduce. This approach is not a
good fit for the dSYM bundle, which is a directory on disk, but should
be treated as a single unit.
On macOS LLDB have automatically find the matching dSYM for a binary by
its UUID. Having a incomplete dSYM in a reproducer can break debugging
even when reproducers are disabled.
This patch adds a was to specify a directory of interest to the
reproducers. It is called from SymbolVendorMacOSX with the path of the
dSYMs used by LLDB.
Differential revision: https://reviews.llvm.org/D76672
In breakpad, only x86 (and mips) registers have a leading '$' in their
names. Arm architectures use plain register names.
Previously, lldb was assuming all registers have a '$'. Fix the code to
match the (unfortunately, inconsistent) reality.
The reason is to add .yaml as a valid test suffix. The test folder
contains one yaml file, which wasn't being run because of that.
Unsurprisingly the test fails, but this was not because the underlying
functionality was broken, but rather because the test was setup
incorrectly (most likely due to overly aggressive simplification of the
test data on my part).
Therefore this patch also tweaks the test inputs in order to test what
they are supposed to test, and also updates some other breakpad tests
(because they depend on the same inputs as this one) to be more
realistic -- specifically it avoids putting symbols to the first page of
the module, as that's where normally the COFF header would reside.
Files imported by the script interpreter aren't opened by LLDB so they
don't end up in the reproducer. The solution is to explicitly add them
to the FileCollector.
Differential revision: https://reviews.llvm.org/D76626
D63643 added these testfiles but some of the %t4dwo and %t5dwo builds
are the same as corresponding %t4 and %t5 builds. Fortunately the
testcases do PASS.
After just adding -gsplit-dwarf these both skeleton files:
tools/lldb/test/SymbolFile/DWARF/Output/debug-types-expressions.test.tmp4dwo
tools/lldb/test/SymbolFile/DWARF/Output/debug-types-expressions.test.tmp5dwo
were referencing to this one non-skeleton file:
tools/lldb/test/SymbolFile/DWARF/debug-types-expressions.dwo
Surprisingly it does not affect the other test debug-types-basic.test
probably because it compiles to .o and then links it. While
debug-types-expressions.test compiles directly to an executable.
So fixed that while keeping the direct executable compilation.
Differential Revision: https://reviews.llvm.org/D76316
The function consisted of a complicated set of conditions to compute the
address ranges which are to be disassembled (depending on the mode
selected by command line switches). This patch creates a separate
function for each mode, so that DoExecute is only left with the task of
figuring out how to dump the relevant ranges.
This is NFC-ish, except for one change in the error message, which is
actually an improvement.
This command had nearly identical code for the "then" and "else"
branches of the "if (m_options.num_instructions != 0)" condition.
This patch factors out the common parts of the two blocks to reduce
duplication.
While we have some tests for this command already, they are very vague.
This is not surprising -- it's hard to make strict assertions about the
assembly if your input is a c++ source file. This means that the tests
can more-or-less only detect when the command breaks completely, and not
when there is a subtle change in meaning due to e.g. a code refactor --
which is something that I am getting ready to do.
This tests in this patch create binaries with well known data (via assembler
and yaml2obj). This means that we are able to make precise assertions
about the text that lldb is supposed to print. As some of the features
of this command are only available with a real process, I use a minidump
core file to create a sufficiently realistic process object.
Summary:
If a command from a sourced file produces asynchronous output, this
output often does not make its way to the user. This happens because the
asynchronous output machinery relies on the iohandler stack to ensure
the output does not interfere with the things the iohandler is doing.
However, if this happens near the end of the command stream then by the
time the asynchronous output is produced we may already have already
started tearing down the sourcing session. Specifically, we may already
pop the relevant iohandler, leaving the stack empty.
This patch makes sure this kind of output gets printed by adding a
fallback to IOHandlerStack::PrintAsync to print the output directly if
the stack is empty. This is safe because if we have no iohandlers then
there is nothing to synchronize.
Reviewers: JDevlieghere, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D75454
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.
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.
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
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
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.
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:
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
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.
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
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
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
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>
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>
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
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
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
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>
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
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>
This patch has a couple of outstanding issues. The test is not python3
compatible, and it also seems to fail with python2 (at least under some
circumstances) due to an overambitious assertion.
This reverts the patch as well as subsequent fixup attempts:
014ea93376,
f5f70d1c8f.
4697e701b8.
5c15e8e682.
3ec28da6d6.
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>
Value::GetValueByteSize() reports the size of a Value as the size of its
underlying CompilerType. However, a host buffer that backs a Value may
be smaller than GetValueByteSize().
This situation arises when the host is only able to partially evaluate a
Value, e.g. because the expression contains DW_OP_piece.
The cleanest fix I've found to this problem is Greg's suggestion, which
is to resize the Value if (after evaluating an expression) it's found to
be too small. I've tried several alternatives which all (in one way or
the other) tried to teach the Value/ValueObjectChild system not to read
past the end of a host buffer, but this was flaky and impractical as it
isn't easy to figure out the host buffer's size (Value::GetScalar() can
point to somewhere /inside/ a host buffer, but you need to walk up the
ValueObject hierarchy to try and find its size).
This fixes an ASan error in lldb seen when debugging a clang binary.
I've added a regression test in test/functionalities/optimized_code. The
point of that test is not specifically to check that DW_OP_piece is
handled a particular way, but rather to check that lldb doesn't crash on
an input that it used to crash on.
Testing: check-lldb, and running the added tests using a sanitized lldb
--
Thanks to Jim for pointing out that an earlier version of this patch,
which simply changed the definition of Value::GetValueByteSize(), would
interact poorly with the ValueObject machinery.
Thanks also to Pavel who suggested a neat way to test this change
(which, incidentally, caught another ASan issue still present in the
original version of this patch).
rdar://58665925
Differential Revision: https://reviews.llvm.org/D73148
Pavel Labath