This ensures that the user is aware that many commands will not work
correctly.
We print the warning only once (per module) to avoid spamming the user
with potentially thousands of error messages.
Differential Revision: https://reviews.llvm.org/D120892
This allows `image lookup -a ... -v` to print variables only if the given
address is covered by the valid ranges of the variables. Since variables created
in dwarf plugin always has empty scope range, print the variable if it has
empty scope.
Differential Revision: https://reviews.llvm.org/D119963
In the rush to get the bot green, I did not realize I was building the
file with -gsplit-dwarf, and therefore the yaml ended up referring to a
file I did not check it.
This rebuilds the file without split dwarf.
In D117744, llvm removed writing support for this format, breaking the
test. We may eventually want to remove reading support as well, but for
now I have converted the test to a yaml file to maintain coverage.
This adds inline function support to NativePDB by parsing S_INLINESITE records
to retrieve inlinee line info and add them into line table at `ParseLineTable`.
Differential Revision: https://reviews.llvm.org/D116845
This allows access type be printed when running `lldb-test -dump-ast` and
`lldb-test -dump-clang-ast`.
Differential Revision: https://reviews.llvm.org/D115062
The pdb lldb tests do not work correctly with both the VS2019 and VS2017 toolsets at the moment. This change updates several of the tests to work with both toolsets. Unfortunately, this makes the tests suboptimal for both toolsets, but we can update them to be better for VS2019 once we officially drop VS2017. This change is meant to bridge the gap until the update happens, so that the buildbots can work with either toolset.
Differential Revision: https://reviews.llvm.org/D115482
This is a split of D113724. Calling `TypeSystemClang::AddMethodToCXXRecordType`
to create function decls for class methods.
Differential Revision: https://reviews.llvm.org/D113930
I don't see a reason why not to. If we allows lookup functions by full names,
I can change the test case in D113930 to use `lldb-test symbols --find=function --name=full::name --function-flags=full ...`,
though the duplicate method decl prolem is still there for `lldb-test symbols --dump-ast`.
That's a seprate bug, we can fix it later.
Differential Revision: https://reviews.llvm.org/D114467
This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.
As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D110216
`image lookup -a ` doesn't work because the compilands list is always empty.
Create CU at given index if doesn't exit.
Differential Revision: https://reviews.llvm.org/D113821
This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.
As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D110216
Teach LLDB to understand INLINE and INLINE_ORIGIN records in breakpad.
They have the following formats:
```
INLINE inline_nest_level call_site_line call_site_file_num origin_num [address size]+
INLINE_ORIGIN origin_num name
```
`INLNIE_ORIGIN` is simply a string pool for INLINE so that we won't have
duplicated names for inlined functions and can show up anywhere in the symbol
file.
`INLINE` follows immediately after `FUNC` represents the ranges of momery
address that has functions inlined inside the function.
Differential Revision: https://reviews.llvm.org/D113330
Since every FUNC record (in breakpad) is a compilation unit, creating the
function for the CU allows `ResolveSymbolContext` to resolve
`eSymbolContextFunction`.
Differential Revision: https://reviews.llvm.org/D113163
The Swift stdlib uses absolute symbols in the dylib to communicate
feature flags to the process. LLDB's expression evaluator needs to be
able to find them. This wires up absolute symbols so they show up in
the symtab lookup command, which is also all that's needed for them to
be visible to the expression evaluator JIT.
rdar://85093828
Differential Revision: https://reviews.llvm.org/D113445
LLDB build were failing due to following two test failures:
lldb-shell :: ObjectFile/ELF/basic-info.yaml
lldb-shell :: SymbolFile/DWARF/x86/debug-types-address-ranges.s
There were caused by commit 6506907a0a
Front-load the first_valid_code_address check, so that we avoid creating
the function object (instead of simply refusing to use it in queries).
Differential Revision: https://reviews.llvm.org/D112310
Based on post-commit review discussion on
2bd8493847 with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
This was originally committed in 277623f4d5
Reverted in f9ad1d1c77 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).
This patch fixes a problem introduced by clang change
https://reviews.llvm.org/D95617 and described by
https://bugs.llvm.org/show_bug.cgi?id=50076#c6, where inlined functions
omit unused parameters both in the stack trace and in `frame var`
command. With this patch, the parameters are listed correctly in the
stack trace and in `frame var` command.
Specifically, we parse formal parameters from the abstract version of
inlined functions and use those formal parameters if they are missing
from the concrete version.
Differential Revision: https://reviews.llvm.org/D110571
specifically, ignore addresses that point before the first code section.
This resurrects D87172 with several notable changes:
- it fixes a bug where the early exits in InitializeObject left
m_first_code_address "initialized" to LLDB_INVALID_ADDRESS (0xfff..f),
which caused _everything_ to be ignored.
- it extends the line table fix to function parsing as well, where it
replaces a similar check which was checking the executable permissions
of the section. This was insufficient because some
position-independent elf executables can have an executable segment
mapped at file address zero. (What makes this fix different is that it
checks for the executable-ness of the sections contained within that
segment, and those will not be at address zero.)
- It uses a different test case, with an elf file with near-zero
addresses, and checks for both line table and function parsing.
Differential Revision: https://reviews.llvm.org/D112058
There is no reason why this function should be returning a ConstString.
While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.
I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.
Differential Revision: https://reviews.llvm.org/D111877
When we know the bounds of the array, print any embedded nuls instead of
treating them as terminators. An exception to this rule is made for the
nul character at the very end of the string. We don't print that, as
otherwise 99% of the strings would end in \0. This way the strings
usually come out the same as how the user typed it into the compiler
(char foo[] = "with\0nuls"). It also matches how they come out in gdb.
This resolves a FIXME left from D111399, and leaves another FIXME for dealing
with nul characters in "escape-non-printables=false" mode. In this mode the
characters cause the entire summary string to be terminated prematurely.
Differential Revision: https://reviews.llvm.org/D111634
This reverts c7f16ab3e3 / r109694 - which
suggested this was done to improve consistency with the gdb test suite.
Possible that at the time GCC did not canonicalize integer types, and so
matching types was important for cross-compiler validity, or that it was
only a case of over-constrained test cases that printed out/tested the
exact names of integer types.
In any case neither issue seems to exist today based on my limited
testing - both gdb and lldb canonicalize integer types (in a way that
happens to match Clang's preferred naming, incidentally) and so never
print the original text name produced in the DWARF by GCC or Clang.
This canonicalization appears to be in `integer_types_same_name_p` for
GDB and in `TypeSystemClang::GetBasicTypeEnumeration` for lldb.
(I tested this with one translation unit defining 3 variables - `long`,
`long (*)()`, and `int (*)()`, and another translation unit that had
main, and a function that took `long (*)()` as a parameter - then
compiled them with mismatched compilers (either GCC+Clang, or
Clang+(Clang with this patch applied)) and no matter the combination,
despite the debug info for one CU naming the type "long int" and the
other naming it "long", both debuggers printed out the name as "long"
and were able to correctly perform overload resolution and pass the
`long int (*)()` variable to the `long (*)()` function parameter)
Did find one hiccup, identified by the lldb test suite - that CodeView
was relying on these names to map them to builtin types in that format.
So added some handling for that in LLVM. (these could be split out into
separate patches, but seems small enough to not warrant it - will do
that if there ends up needing any reverti/revisiting)
Differential Revision: https://reviews.llvm.org/D110455
This patch considers the CU index entry
when reading the .debug_rnglists.dwo section.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D107456
Fix D98289 so that it works even for 2nd..nth compilation unit
(.debug_rnglists).
Reviewed By: dblaikie, ikudrin
Differential Revision: https://reviews.llvm.org/D106466
This test is specifying the lldb log channel via `ll""db` which only really works
because the command parser ends up parsing that as `lldb`. Just putting the
channel name in quotes is enough to avoid the lldb command substitution and
doesn't rely on this weird parser behaviour.
Skeleton vs. DWO units mismatch has been fixed in D106270. As they both
have type DWARFUnit it is a bit difficult to debug. So it is better to
make it safe against future changes.
Reviewed By: kimanh, clayborg
Differential Revision: https://reviews.llvm.org/D107659
When going through the CU entries in the name index,
make sure to compare the name entry's CU
offset against the skeleton CU's offset.
Previously there would be a mismatch, since the
wrong offset was compared, and thus no suitable
entry was found.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D106270
Summary:
In the spirit of https://reviews.llvm.org/D70846, we only return functions with
matching mangled name from Apple/DebugNamesDWARFIndex::GetFunction if
eFunctionNameTypeFull is requested.
This speeds up lookup in the presence of large amount of class methods of the
same name (a typical examples would be constructors of templates with many
instantiations or overloaded operators).
Reviewers: labath, teemperor
Reviewed By: labath, teemperor
Subscribers: aprantl, arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73191
This patch fixes the lookup of locations in
.debug_loclists, if they are split in a .dwp file.
Mainly, we need to consider the cu index offsets.
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D107161
In some environments this test could fail if start.S has its own DWARF
CompileUnit or similar are included before the DWARF CompileUnit for the
file.
This change makes the test independent of the index of the compile unit,
instead checking the filename.
Reviewed By: herhut, jankratochvil
Differential Revision: https://reviews.llvm.org/D107300
This change makes sure that DwarfUnit does not load a .dwo file until
necessary. I also take advantage of DWARF 5's guarantee that the first
support file is also the primary file to make it possible to create
a compile unit without loading the .dwo file.
Testcases now require Linux as it is needed for -gsplit-dwarf.
Review By: jankratochvil, dblaikie
Differential Revision: https://reviews.llvm.org/D100299
