I found a few cases where entries in the debug_line for a specific line of code have invalid entries (the address is outside of a code section or no section at all) and also valid entries. When this happens lldb might not set the breakpoint because the first line entry it will find in the line table might be the invalid one and since it's range is "invalid" no location is resolved. To get around this I changed the way we parse the line sequences to ignore those starting at an address under the first code segment.
Greg suggested to implement it this way so we don't need to check all sections for every line sequence.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D87172
This would be reproducible in future DWZ category of the testsuite as:
Failed Tests (1):
lldb-api :: python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
Differential Revision: https://reviews.llvm.org/D91014
Current user_id_t format is:
63{isDebugTypes} 62..32{dwo || 7fffffff}
31..0 {die_offset}
while current DIERef format is (I have made up the bit positions but the
field widths do match):
63{m_section==isDebugTypes} 62{m_dwo_num_valid} 61..32{m_dwo_num}
31..0 {m_die_offset}
Proposing to change user_id_t to:
63{isDebugTypes} 62{dwo_is_valid} 61..32{dwo; 0 if !valid}
31..0 {die_offset}
There is no benefit of having 31-bits wide dwo_num in user_id_t when it
gets converted to 30-bits width in DIERef.
This patch is for future DWZ patchset which extends the dwo_is_valid bit
into a 2-bit field (normal, DWO, DWZ, DWZcommon) so that both user_id_t
and DIERef can be changed then the same way.
It would be best to somehow unify user_id_t and DIERef but I do not plan
to do that. user_id_t should probably remain a number for the Python API
compatibility while there still needs to be some class with all the
methods to access it.
SymbolFileDWARF::GetDwpSymbolFile() and SymbolFileDWARF::GetDIE use
0x3fffffff for DWP but that does not clash:
formerly:
31bits32..62:0x7fffffff = normal unit / not any DWO
31bits32..62:0x3fffffff = DWP
31bits32..62:others = DWO unit number
after this patch:
bit62=0 30bits32..61:any = normal unit / not any DWO
bit62=1 30bits32..61:0x3fffffff = DWP
bit62=1 30bits32..61:others = DWO unit number
Differential Revision: https://reviews.llvm.org/D90413
There were invalid DIE references which nobody used. If LLDB starts to
report invalid DIE references it would lock up (mutex lock).
These invalid DIE references are there since initial check-in by:
https://reviews.llvm.org/D83302
The function was returning an incorrect (empty) value on the first
invocation. Given that this only affected the first invocation, this
bug/typo went mostly unaffected. DW_AT_const_value were particularly
badly affected by this as the GetByteSize call is
SymbolFileDWARF::ParseVariableDIE is likely to be the first call of this
function, and its effects cannot be undone by retrying.
Depends on D86348.
Differential Revision: https://reviews.llvm.org/D86436
Class-level static constexpr variables can have both DW_AT_const_value
(in the "declaration") and a DW_AT_location (in the "definition")
attributes. Our code was trying to handle this, but it was brittle and
hard to follow (and broken) because it was processing the attributes in
the order in which they were found.
Refactor the code to make the intent clearer -- DW_AT_location trumps
DW_AT_const_value, and fix the bug which meant that we were not
displaying these variables properly (the culprit was the delayed parsing
of the const_value attribute due to a need to fetch the variable type.
Differential Revision: https://reviews.llvm.org/D86615
This fixes several issues in handling of DW_AT_const_value attributes:
- the first is that the size of the data given by data forms does not
need to match the size of the underlying variable. We already had the
case to handle this for DW_FORM_(us)data -- this extends the handling
to other data forms. The main reason this was not picked up is because
clang uses leb forms in these cases while gcc prefers the fixed-size
ones.
- The handling of DW_AT_strp form was completely broken -- we would end
up using the pointer value as the result. I've reorganized this code
so that it handles all string forms uniformly.
- In case of a completely bogus form we would crash due to
strlen(nullptr).
Depends on D86311.
Differential Revision: https://reviews.llvm.org/D86348
In some cases when we have a DW_AT_const_value and the data can be found in the
DWARFExpression then ValueObjectVariable does not handle it properly and we end
up with an extracting data from value failed error.
The test is a very stripped down assembly file since reproducing this relies on the results of compiling with -O1 which may not be stable over time.
Differential Revision: https://reviews.llvm.org/D86311
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
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
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
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
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
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.
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.
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
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
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
