| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
(#180987)
Follow-up from
https://github.com/llvm/llvm-project/pull/180612#pullrequestreview-3780142672
This was introduced in 2af3416618e6 and not fundamentally changed since.
The review (https://reviews.llvm.org/D54452) doesn't mention any
motivation for why we would want the pointee size/signedness here. As
@Nerixyz points out, only a null pointer can be `S_CONSTANT` anyway.
|
|
This is mostly to support Swift `let`, but I found a way to get MSVC to
emit a local `S_CONSTANT` (see test).
I saw the note about `MakeConstantLocalExpression` at
https://github.com/llvm/llvm-project/blob/2e34fecf02962e4c8477ca88cc5ac9386a0f76bb/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp#L2177
but couldn't repro with local or global (emitted as `S_LDATA32` in both
cases).
|
|
variables (#181011)
LLVM added support for emitting the tagging offset of a variable for
hwasan/memtag-stack using the DW_AT_LLVM_tag_offset attribute in
dabd262. This patch teaches LLDB to read this attribute.
|
|
In #168245, I attempted to dump the available settings to Markdown. That
required a full build of LLDB. However, to build the docs, only the swig
wrappers should need to be compiled. The comment was that we should be
able to use the definitions from the TableGen files.
Currently, the property definitions in don't have information about the
path where they will be available. They only contain a `Definition`
which groups properties, so they can be added to
`OptionValueProperties`.
With this PR, I'm adding the path for each property definition. For
example, `symbols.enable-external-lookup` would have `Name =
enable-external-lookup, Path = symbols`. In LLDB itself, we don't need
this path, we only need it for the documentation. To avoid mismatches
between the actual path and the declared one, I added a debug-only check
when a property group is added to a parent
(`OptionValueProperties::AppendProperty`).
The TableGen emitter for the properties now additionally emits
`g_{definition}_properties_def`, which includes both the array of
properties and the expected path. This constant has to be used to
initialize a `OptionValueProperties`.
I couldn't test this for everything (e.g. IntelPT or ProcessKDP), but
the necessary changes are simple: (1) set the `Path` in the TableGen
file, (2) update `initialize` to use `_def`.
|
|
This is part of a patch series to clean up the
`TypeSystemClang::IsFloatingPointType` API. Currently the API is a bit
of a foot-gun because it returns `true` for both Complex floats and
vector types whose element types are floats, but most call-sites
probably don't handle these correctly. The former aligns with the
`clang::Type::isFloatingType` API, but the latter doesn't. This specific
implementation choice will be addressed in a separate patch. This patch
adds a new `CompilerType::IsRealFloatingPointType` API which clients can
use to query about non-complex floats (named after the similarly named
`clang::Type::isRealFloatingType`).
This allows us to clean up some of the callers which only wanted to
handle non-complex floats. I cleaned those up as part of this patch.
Wherever we checked for `is_float && !is_complex && !is_vector_type` i
just replaced it with the new API.
On encountering complex/vector floats, some of the ABI plugins would set
an error but then immediately overwrite the error to something else. I
just removed those branches entirely, since it was essentially dead
code.
Some of the diff is large because of un-indentation when we remove
if-guards, so I would recommend turning off white-space diff when
reviewing.
|
|
|
|
GetTypeSystemForLanguage (#178667)
Removes duplicated code by simply calling into the base-class.
Motivation is just that I stumbled upon this when making changes in the
surrounding area.
|
|
LLDB's DWARF parser didn't support parsing DW_FORM_GNU_ref_alt and
DW_FORM_GNU_strp_alt forms which would cause any file loaded by LLDB to
fail to parse any DWARF. Added support for parsing this information
only, not for actually finding the debug info reference to an alternate
file or a string in an alternate file. These extensions are used by DWZ
files which are present in some linux distros, so it will be good for
LLDB to just be able to parse these without emitting an error like:
(lldb) b bar
warning: (arm64) /tmp/a.out unsupported DW_FORM values: 0x1f20 0x1f21
|
|
(#166455)
Fix crash when an inline site record in the PDB file contains type index
which is out of bounds
|
|
These are the places that required no modifications to surrounding code.
|
|
Currently we forcefully complete C++ types if we can't find their
definition for layout purposes. This ensures that we at least don't
crash in Clang when laying out the type. The definition is required for
types of members/array elements/base classes for the purposes of
calculating their layout. This is also true for Obj-C types, but we
haven't been forcefully completing those.
The test-case that's being un-XFAILed in this patch demonstrates a case
where not completing the super-class forcefully causes a clang crash.
rdar://168440264
|
|
Uncommenting `ENABLE_DEBUG_PRINTF` wasn't compiling on top-of-tree. This code may have been useful for debugging locally in the past but it doesn't seem compelling to keep this in the source-tree. Especially because it doesn't compile, indicating it's most likely not used.
This patch removes `DEBUG_PRINTF` entirely.
|
|
(#176491)
Introducing `llvm::createStringErrorV` caused a `0.5%` compile-time
regression because it's an inline function in a core header. This moves
the API to a new header to prevent including this function in files that
don't need it.
Also includes the header in the source files that have been using
`createStringErrorV` (which currently is just LLDB).
|
|
createStringErrorV (#176428)
Makes use of the recently introduced `llvm::createStringErrorV` API.
It's designed exactly for this use-case.
|
|
`TypeSystem::GetNativePDBParser` returns `nullptr` by default, so using
the result without checking can cause a crash.
|
|
|
|
This changes `PdbAstBuilder` to a language-neutral abstract interface
and moves all of its functionality to the `PdbAstBuilderClang` derived
class.
All Clang-specific methods with external callers are now public methods
on `PdbAstBuilderClang`. `TypeSystemClang` and `UdtRecordCompleter` use
`PdbAstBuilderClang` directly.
Did my best to clean up includes and unused methods.
RFC for context:
https://discourse.llvm.org/t/rfc-lldb-make-pdbastbuilder-language-agnostic/89117
|
|
Currently, `SymbolFileNativePDB` calls several `PdbAstBuilder` methods
for side-effects to ensure the AST is populated.
This change adds new void-returning methods for `SymbolFileNativePDB` to
use as a hook instead, so that it doesn't depend on Clang-specific parts
of `PdbAstBuilder`'s interface.
This is part of the work to allow language-agnostic `PdbAstBuilder` (see
RFC:
https://discourse.llvm.org/t/rfc-lldb-make-pdbastbuilder-language-agnostic/89117)
|
|
Missed this one in https://github.com/llvm/llvm-project/pull/173111
Also tweaks `PdbAstBuilder::ToCompilerType` to make it more clear that
the change is correct and take advantage of asserts in `TypeSystemClang`
This is part of the work to allow language-agnostic `PdbAstBuilder` (see
RFC:
https://discourse.llvm.org/t/rfc-lldb-make-pdbastbuilder-language-agnostic/89117)
|
|
Follow-up to https://github.com/llvm/llvm-project/pull/173111
`ToCompilerDeclContext` and `ToCompilerDecl` take their arguments as
references, but all callers are pointers. This changes the signature to
take pointers, then addresses the comments at
https://github.com/llvm/llvm-project/pull/173111#discussion_r2673140167
|
|
(#173111)
This change implements part of
https://discourse.llvm.org/t/rfc-lldb-make-pdbastbuilder-language-agnostic/89117,
the goal of which is make `PdbAstBuilder` language-agnostic.
It adds several new interface methods to `PdbAstBuilder` which allow
`SymbolFileNativePDB` to interact with it without using Clang-specific
types. These new methods would make up much of the interface of a future
abstract `PdbAstBuilder`. `SymbolFileNativePDB` is updated to use these.
The old Clang-specific methods were renamed if used by
`UdtRecordCompleter` or internally, or removed where possible.
|
|
The list table header size was always computed assuming `DWARF32`, even
when parsing `DWARF64` units. This results in an incorrect header size
for `DWARF64` and can cause mis-parsing of list tables.
Fix this by using the Dwarf Format from the form parameters instead of
always assuming `DWARF32` when computing the `DWARF` header size.
|
|
Instead of changing an existing LookupInfo after creation, let's make
them constant.
|
|
Typedef/using declarations in structs and classes were not created with
the native PDB plugin. The following would only create `Foo` and
`Foo::Bar`:
```cpp
struct Foo {
struct Bar {};
using Baz = Bar;
using Int = int;
};
```
With this PR, they're created. One complication is that typedefs and
nested types show up identical. The example from above gives:
```
0x1006 | LF_FIELDLIST [size = 40, hash = 0x2E844]
- LF_NESTTYPE [name = `Bar`, parent = 0x1002]
- LF_NESTTYPE [name = `Baz`, parent = 0x1002]
- LF_NESTTYPE [name = `Int`, parent = 0x0074 (int)]
```
To distinguish nested types and typedefs, we check if the parent of a
type is equal to the current one (`parent(0x1002) == 0x1006`) and if the
basename matches the nested type name.
|
|
(#166845)
We used to search for constants using the name we parsed. For C++, this
would mean using the demangled struct name (from the unique name). This
name is not always equal to the one used for the struct's name by the
compiler. For example:
```
0x105E | LF_STRUCTURE [size = 120, hash = 0xF38F] ``anonymous namespace'::Anonymous<A::B::C<void> >::D`
unique name: `.?AUD@?$Anonymous@U?$C@X@B@A@@@?A0x8C295248@@`
```
We would use the unique name and get to `(anonymous
namespace)::Anonymous<struct A::B::C<void>>::D`. Then, when finding the
constant in the field list, we'd search for `(anonymous
namespace)::Anonymous<struct A::B::C<void>>::D::StaticMember`. This
wouldn't yield any results, because the constant will use the demangled
name as given by the compiler.
With this PR, we use the struct's name as given in the PDB and append
the member name.
|
|
This reverts commit
https://github.com/llvm/llvm-project/commit/54a4da9df6906b63878ad6d0ea6da3ed7d2d8432.
MSVC supports an extension allowing to delete an array of objects via
pointer whose static type doesn't match its dynamic type. This is done
via generation of special destructors - vector deleting destructors.
MSVC's virtual tables always contain a pointer to the vector deleting
destructor for classes with virtual destructors, so not having this
extension implemented causes clang to generate code that is not
compatible with the code generated by MSVC, because clang always puts a
pointer to a scalar deleting destructor to the vtable. As a bonus the
deletion of an array of polymorphic object will work just like it does
with MSVC - no memory leaks and correct destructors are called.
This patch will cause clang to emit code that is compatible with code
produced by MSVC but not compatible with code produced with clang of
older versions, so the new behavior can be disabled via passing
-fclang-abi-compat=21 (or lower).
Fixes https://github.com/llvm/llvm-project/issues/19772
|
|
The ObjectFile plugin interface accepts an optional DataBufferSP
argument. If the caller has the contents of the binary, it can provide
this in that DataBufferSP. The ObjectFile subclasses in their
CreateInstance methods will fill in the DataBufferSP with the actual
binary contents if it is not set.
ObjectFile base class creates an ivar DataExtractor from the
DataBufferSP passed in.
My next patch will be a caller that creates a VirtualDataExtractor with
the binary data, and needs to pass that in to the ObjectFile plugin,
instead of the bag-of-bytes DataBufferSP. It builds on the previous
patch changing ObjectFile's ivar from DataExtractor to DataExtractorSP
so I could pass in a subclass in the shared ptr. And it will be using
the VirtualDataExtractor that Jonas added in
https://github.com/llvm/llvm-project/pull/168802
No behavior is changed by the patch; we're simply moving the creation of
the DataExtractor to the caller, instead of a DataBuffer that is
immediately used to set up the ObjectFile DataExtractor. The patch is a
bit complicated because all of the ObjectFile subclasses have to
initialize their DataExtractor to pass in to the base class.
I ran the testsuite on macOS and on AArch64 Ubutnu. (btw David, I ran it
under qemu on my M4 mac with SME-no-SVE again, Ubuntu 25.10, checked
lshw(1) cpu capabilities, and qemu doesn't seem to be virtualizing the
SME, that explains why the testsuite passes)
rdar://148939795
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
|
|
Some months ago, the LookupInfo constructor logic was refactored to not
depend on language specific logic, and use languages plugins instead. In
this refactor, when the language type is unknown, a single LookupInfo
object will handle multiple languages. This doesn't work well, as
multiple languages might want to configure the LookupInfo object in
different ways. For example, different languages might want to set the
m_lookup_name differently from each other, but the previous
implementation would pick the first name a language provided, and
effectively ignored every other language. Other fields of the LookupInfo
object are also configured in incompatible ways.
This approach doesn't seem to be a problem upstream, since only the
C++/Objective-C language plugins are available, but it broke downstream
on the Swift fork, as adding Swift to the list of default languages when
the language type is unknown breaks C++ tests.
This patch makes it so instead of building a single LookupInfo object
for multiple languages, one LookupInfo object is built per language
instead.
rdar://159531216
|
|
DW_TAG_typedef (#170135)
Depends on:
* https://github.com/llvm/llvm-project/pull/170132
Clang gained the `-gtemplate-alias` not too long ago, which emits C++
alias templates as `DW_TAG_template_alias` (instead of
`DW_TAG_typedef`). The main difference is that `DW_TAG_template_alias`
has `DW_TAG_template_XXX` children. The flag was not enabled by default
because consumers (mainly LLDB) didn't know how to handle it. This patch
adds rudimentary support for debugging with `DW_TAG_template_alias`.
This patch simply creates the same kind of `TypedefDecl` as we do for
`DW_TAG_typedef`. The more complete solution would be to create a
`TypeAliasTemplateDecl` and associated `TypeAliasDecl`. But that would
require DWARF to carry generic template information, but currently each
`DW_TAG_template_alias` represents a concrete instantiation. We could
probably hack up some working AST representation that includes the
template parameters, but I currently don't see a compelling reason to.
All we need is the `DW_AT_name` and the `DW_AT_type` that the typedef
refers to.
rdar://137499401
|
|
(#170249)
We almost had RTTI support for `DWARFASTParserClang`, but because
`classof` was protected, using `llvm::cast`/etc. on it would fail to
compile with:
```
llvm/include/llvm/Support/Casting.h:64:57: error: 'classof' is a protected member of 'DWARFASTParserClang'
64 | static inline bool doit(const From &Val) { return To::classof(&Val); }
| ^
llvm/include/llvm/Support/Casting.h:110:32: note: in instantiation of member function 'llvm::isa_impl<DWARFASTParserClang, lldb_private::plugin::dwarf::DWARFASTParser>::doit' requested here
110 | return isa_impl<To, From>::doit(*Val);
```
This patch makes `classof` public and turns `static_cast`s of
`DWARFASTParserClang` into `llvm::cast`s.
|
|
Similar to DWARF's DWO, we should look for PDBs in
`target.debug-file-search-paths` if the PDB isn't at the original
location or next to the executable.
With this PR, the search order is as follows:
1. PDB path specified in the PE/COFF file
2. Next to the executable
3. In `target.debug-file-search-paths`
This roughly matches [the order Visual Studio
uses](https://learn.microsoft.com/en-us/visualstudio/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger?view=vs-2022#where-the-debugger-looks-for-symbols),
except that we don't have a project folder and don't support symbol
servers.
Closes #125355 (though I think this is already fixed in the native
plugin).
|
|
When a PDB is loaded through `target symbols add <pdb-path>`, its
`m_objectfile_sp` is an `ObjectFilePDB` instead of `ObjectFilePECOFF`
(the debugged module). In both the native and DIA plugin, some paths
assumed that `m_objectfile_sp` is the debugged module. With this PR,
they go through `m_objfile_sp->GetModule()->GetObjectFile()`.
For the DIA plugin, this lead to an assertion failure
(https://github.com/llvm/llvm-project/issues/169628#issuecomment-3582555277)
and for both plugins, it meant that the symbol table wasn't loaded.
|
|
(#169506)
this avoids allocation when checking if a method contains a path.
|
|
(#169116)
This reverts 4d10c1165442cbbbc0017b48fcdd7dae1ccf3678 and its two
dependent commits: e6b9805b574bb5c90263ec7fbcb94df76d2807a4 and
c243406a695ca056a07ef4064b0f9feee7685320, see discussion in
https://github.com/llvm/llvm-project/pull/165598#issuecomment-3563825509.
|
|
This patch fixes and eliminates the possibility of SupportFileSP ever
being nullptr. The support file was originally treated like a value
type, but became a polymorphic type and therefore has to be stored and
passed around as a pointer.
To avoid having all the callers check the validity of the pointer, I
introduced the invariant that SupportFileSP is never null and always
default constructed. However, without enforcement at the type level,
that's fragile and indeed, we already identified two crashes where
someone accidentally broke that invariant.
This PR introduces a NonNullSharedPtr to prevent that. NonNullSharedPtr
is a smart pointer wrapper around std::shared_ptr that guarantees the
pointer is never null. If default-constructed, it creates a
default-constructed instance of the contained type. Note that I'm using
private inheritance because you shouldn't inherit from standard library
classes due to the lack of virtual destructor. So while the new
abstraction looks like a `std::shared_ptr`, it is in fact **not** a
shared pointer. Given that our destructor is trivial, we could use
public inheritance, but currently there's no need for it.
rdar://164989579
|
|
Currently LLDB's `ParseRustVariantPart` generates the following
`CXXRecordDecl` for a Rust enum
```rust
enum AA {
A(u8)
}
```
```
CXXRecordDecl 0x5555568d5970 <<invalid sloc>> <invalid sloc> struct AA
|-CXXRecordDecl 0x5555568d5ab0 <<invalid sloc>> <invalid sloc> union test_issue::AA$Inner definition
| |-CXXRecordDecl 0x5555568d5d18 <<invalid sloc>> <invalid sloc> struct A$Variant definition
| | |-DefinitionData pass_in_registers aggregate standard_layout trivially_copyable trivial
| | | `-Destructor simple irrelevant trivial needs_implicit
| | `-FieldDecl 0x555555a77880 <<invalid sloc>> <invalid sloc> value 'test_issue::AA::A'
| `-FieldDecl 0x555555a778f0 <<invalid sloc>> <invalid sloc> $variant$ 'test_issue::AA::test_issue::AA$Inner::A$Variant'
|-CXXRecordDecl 0x5555568d5c48 <<invalid sloc>> <invalid sloc> struct A definition
| `-FieldDecl 0x555555a777e0 <<invalid sloc>> <invalid sloc> __0 'unsigned char'
`-FieldDecl 0x555555a77960 <<invalid sloc>> <invalid sloc> $variants$ 'test_issue::AA::test_issue::AA$Inner'
```
While when the Rust enum type name is the same as its variant name, the
generated `CXXRecordDecl` becomes the following – there's a circular
reference between `struct A$Variant` and `struct A`, causing #163048.
```rust
enum A {
A(u8)
}
```
```
CXXRecordDecl 0x5555568d5760 <<invalid sloc>> <invalid sloc> struct A
|-CXXRecordDecl 0x5555568d58a0 <<invalid sloc>> <invalid sloc> union test_issue::A$Inner definition
| |-CXXRecordDecl 0x5555568d5a38 <<invalid sloc>> <invalid sloc> struct A$Variant definition
| | `-FieldDecl 0x5555568d5b70 <<invalid sloc>> <invalid sloc> value 'test_issue::A' <---- bug here
| `-FieldDecl 0x5555568d5be0 <<invalid sloc>> <invalid sloc> $variant$ 'test_issue::A::test_issue::A$Inner::A$Variant'
`-FieldDecl 0x5555568d5c50 <<invalid sloc>> <invalid sloc> $variants$ 'test_issue::A::test_issue::A$Inner'
```
The problem was caused by `GetUniqueTypeNameAndDeclaration` not
returning the correct qualified name for DWARF DIE `test_issue::A::A`,
instead, it returned `A`. This caused `ParseStructureLikeDIE` to find
the wrong type `test_issue::A` and returned early.
The failure in `GetUniqueTypeNameAndDeclaration` appears to stem from a
language check that returns early unless the language is C++. I changed
it so Rust follows the C++ path rather than returning. I’m not entirely
sure this is the right approach — Rust’s qualified name rules look
similar, but not identical? Alternatively, we could add a Rust-specific
implementation that forms qualified names according to Rust's rules.
|
|
DWARF units in .dwp files in LLDB. (#167997)
This patch is updating the reading capabilities of the LLDB DWARF parser
for a llvm-dwp patch https://github.com/llvm/llvm-project/pull/167457
that will emit .dwp files where the compile units are DWARF32 and the
.debug_str_offsets tables will be emitted as DWARF64 to allow .debug_str
sections that exceed 4GB in size.
|
|
MSVC supports an extension allowing to delete an array of objects via
pointer whose static type doesn't match its dynamic type. This is done
via generation of special destructors - vector deleting destructors.
MSVC's virtual tables always contain a pointer to the vector deleting
destructor for classes with virtual destructors, so not having this
extension implemented causes clang to generate code that is not
compatible with the code generated by MSVC, because clang always puts a
pointer to a scalar deleting destructor to the vtable. As a bonus the
deletion of an array of polymorphic object will work just like it does
with MSVC - no memory leaks and correct destructors are called.
This patch will cause clang to emit code that is compatible with code
produced by MSVC but not compatible with code produced with clang of
older versions, so the new behavior can be disabled via passing
-fclang-abi-compat=21 (or lower).
This is yet another attempt to land vector deleting destructors support
originally implemented by
https://github.com/llvm/llvm-project/pull/133451.
This PR contains fixes for issues reported in the original PR as well as
fixes for issues related to operator delete[] search reported in several
issues like
https://github.com/llvm/llvm-project/pull/133950#issuecomment-2787510484
https://github.com/llvm/llvm-project/issues/134265
Fixes https://github.com/llvm/llvm-project/issues/19772
|
|
Main executables were bypassing the locate module callback that shared
libraries use, preventing custom symbol file location logic from working
consistently.
This PR fix this by
* Adding target context to ModuleSpec
* Leveraging that context to use target search path and platform's
locate module callback in ModuleList::GetSharedModule
This ensures both main executables and shared libraries get the same
callback treatment for symbol file resolution.
---------
Co-authored-by: George Hu <hyubo@meta.com>
Co-authored-by: George Hu <georgehuyubo@gmail.com>
|
|
When anonymous unions are used in a struct or vice versa, their fields
are merged into the parent record when using PDB. LLDB tries to recreate
the original definition of the record _with_ the anonymous
unions/structs.
For tagged unions (like `std::optional`) where the tag followed the
anonymous union, the result was suboptimal:
```cpp
// input:
struct Foo {
union {
Bar b;
char c;
};
bool tag;
};
// reconstructed:
struct Foo {
union {
Bar b;
struct {
char c;
bool tag;
};
};
};
```
Once the algorithm is in some nested union, it can't get out.
In the above case, we can get to the correct reconstructed record if we
always add fields that don't overlap others in the root struct. So when
we see `tag`, we'll see that it comes after all other fields, so it's
possible to add it in the root `Foo`.
|
|
Small change to use (what I think is) a better practice -- we were using
the `m_indexed` bool member to make sure we called `Index()` once, but
we should just use `std::once`! This change shouldn't affect
functionality.
This change may also make concurrent access to `Index()` thread-safe,
though the ManualDWARFIndex API isn't completely thread-safe due to
`Decode()`. I'm not sure if ManualDWARFIndex was ever intended to be
thread-safe.
Test Plan:
`ninja check-lldb`
Tested basic debugging workflow of a couple of large projects I had
built. Basically:
```
(lldb) target create <project>
(lldb) b main
(lldb) r
(lldb) step
...
```
I A/B tested the performance of launching several modules with parallel
module loading and didn't observe any performance regressions.
---------
Co-authored-by: Tom Yang <toyang@fb.com>
|
|
Depends on:
* https://github.com/llvm/llvm-project/pull/165686
This patch ensures we make use of the `DW_AT_bit_size` on
`DW_TAG_base_type`s (which since
https://github.com/llvm/llvm-project/pull/164372 can exist on
`_BitInt`s) and adjusts `TypeSystemClang` to recognize `_BitInt`.
For DWARF from older versions of Clang that didn't emit a
`DW_AT_bit_size`, we would create `_BitInt`s using the byte-size. Not
sure we can do much better than that. But the situation beforehand
wasn't much better.
Before:
```
(lldb) v
(char) a = '\x01'
(unsigned char) b = '\x01'
(long) c = 2
(unsigned long) d = 2
```
After:
```
(lldb) v
(_BitInt(2)) a = 1
(unsigned _BitInt(2)) b = 1
(_BitInt(52)) c = 2
(unsigned _BitInt(52)) d = 2
```
Fixes https://github.com/llvm/llvm-project/issues/110273
|
|
TypeSystem::IsFloatingPointType (#165707)
Similar motivation to https://github.com/llvm/llvm-project/pull/165702.
It was unused in all callsites and inconsistent with other APIs like
`IsIntegerType` (which doesn't take a `count` parameter).
If we ever need a "how many elements does this type represent", we can
implement one with a new TypeSystem API that does exactly that.
Some callsites checked for `count == 1` previously, but I suspect what
they intended to do is check for whether it's a vector type or complex
type, before reading the FP register. I'm somewhat confident that's the
case because the `TypeSystemClang::GetTypeInfo` currently incorrectly
sets the integer and floating point bits for complex and vector types
(will fix separately). But some architectures might choose to pass
single-element vectors in scalar registers. I should probably changes
these to check the vector element size.
All the `count == 2 && is_complex` were redundant because `count == 2`
iff `is_complex == true`. So I just removed the count check there.
|
|
In #165604, a test was skipped on Windows, because the native PDB plugin
didn't set sizes on symbols. While the test isn't compiled with debug
info, it's linked with `-gdwarf`, causing a PDB to be created on
Windows. This PDB will only contain the public symbols (written by the
linker) and section information. The symbols themselves don't have a
size, however the DIA SDK sets a size for them.
It seems like, for these data symbols, the size given from DIA is the
distance to the next symbol (or the section end).
This PR implements the naive approach for the native plugin. The main
difference is in function/code symbols. There, DIA searches for a
corresponding `S_GPROC32` which have a "code size" that is sometimes
slightly smaller than the difference to the next symbol.
|
|
One (DWARF-spec compliant) exmample is:
https://github.com/llvm/llvm-project/pull/164372, where we attach a
`DW_AT_bit_size` to `_BitInt` types that can't be exactly described by a
byte-size.
This patch adds support for `DW_AT_bit_size` to `DWARFASTParserClang`
when parsing type tags.
Note, we don't use this bit-size yet, but will do so in follow-up
patches.
|
|
All PDB tests now pass when compiled without DIA on Windows, so they
pass with the native reader.
With this PR, the default reader changes to the native reader.
The plan is to eventually remove the DIA reader (see
https://discourse.llvm.org/t/rfc-removing-the-dia-pdb-plugin-from-lldb/87827
and #114906).
For now, DIA can be used by setting `plugin.symbol-file.pdb.reader` to
`dia` or by setting `LLDB_USE_NATIVE_PDB_READER=0` (mostly undocumented,
but used in tests).
|
|
(#154123)
[lldb][DWARFASTParserClang] Added a check for the specialization
existence
While debugging an application with incorrect dwarf information, where
DW_TAG_template_value_parameter was lost, I found that lldb does not
check that the corresponding specialization exists. As a result, at the
stage when ASTImporter works, the type is completed in such a way that
it inherits from itself. And during the calculation of layout, an
infinite recursion occurs. To catch this error, I added a corresponding
check
at the stage of restoring the type from dwarf information. I also added
a
trivial assert in clang to check that the class does not inherit from
itself.
|
|
types (#163621)
When creating all types in a compilation unit, simple types (~>
primitive and pointer types) that were only used in function arguments
or return types weren't created as LLDB `Type`s.
With this PR, they're created when creating the function/method types.
This makes it possible to run the `SymbolFile/PDB/typedefs.test` with
both plugins.
|
|
This aligns the simple types created by the native plugin with the ones
from DIA as well as LLVM and the original cvdump.
- A few type names weren't handled when creating the LLDB `Type` name
(e.g. `short`)
- 64-bit integers were created as `(u)int64_t` and are now created as
`(unsigned) long long` (matches DIA)
- 128-bit integers (only supported by clang-cl) weren't created as types
(they have `SimpleTypeKind::(U)Int128Oct`)
- All complex types had the same name - now they have `_Complex
<float-type>`
Some types like `SimpleTypeKind::Float48` can't be tested because they
can't be created in C++.
|
|
Before this PR, the native PDB plugin would create the following LLDB
`Type` for `using SomeTypedef = long`:
```
Type{0x00002e03} , name = "SomeTypedef", size = 4, compiler_type = 0x000002becd8d8620 long
```
with this PR, the following is created:
```
Type{0x00002e03} , name = "SomeTypedef", size = 4, compiler_type = 0x0000024d6a7e3c90 typedef SomeTypedef
```
This matches the behavior of the DIA PDB plugin and works towards making
[`Shell/SymbolFile/PDB/typedefs.test`](https://github.com/llvm/llvm-project/blob/main/lldb/test/Shell/SymbolFile/PDB/typedefs.test)
pass with the native plugin.
I added a similar test to the `NativePDB` shell tests to capture the
current state, which doesn't quite match that of DIA yet. I'll add some
comments on what's missing on this PR, because I'm not fully sure what
the correct output would be.
|
