Given something like:
struct S {
int a;
struct { int b; };
};
We would fail to give 'b' offset 4. Instead, we would give it the
offset it has inside of it's struct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274400 91177308-0d34-0410-b5e6-96231b3b80d8
A namespace without a name should be written out as `anonymous
namespace' while a tag type without a name should be written out as
<unnamed-tag>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274399 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC makes up names for these anonymous structs, but we don't (yet).
Eventually Clang should use getTypedefNameForAnonDecl() to put some name
in the debug info, and we can update the test case when that happens.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274391 91177308-0d34-0410-b5e6-96231b3b80d8
We were asserting that our type records were valid when emitting
assembly, but not when emitting an object file.
I've been seeing lots of LNK1285 errors (corrupt PDB) during incremental
debug self-host builds with the MSVC linker, and hopefully this will
catch some of them earlier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274373 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This represents the adjustment applied to the implicit 'this' parameter
in the prologue of a virtual method in the MS C++ ABI. The adjustment is
always zero unless multiple inheritance is involved.
This increases the size of DISubprogram by 8 bytes, unfortunately. The
adjustment really is a signed 32-bit integer. If this size increase is
too much, we could probably win it back by splitting out a subclass with
info specific to virtual methods (virtuality, vindex, thisadjustment,
containingType).
Reviewers: aprantl, dexonsmith
Subscribers: aaboud, amccarth, llvm-commits
Differential Revision: http://reviews.llvm.org/D21614
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274325 91177308-0d34-0410-b5e6-96231b3b80d8
CodeView need to know the offset of the storage allocation for a
bitfield. Encode this via the "extraData" field in DIDerivedType and
introduced a new flag, DIFlagBitField, to indicate whether or not a
member is a bitfield.
This fixes PR28162.
Differential Revision: http://reviews.llvm.org/D21782
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274200 91177308-0d34-0410-b5e6-96231b3b80d8
Clang emits them in reverse order to conform to the ABI, which requires
left-to-right destruction. As a result, the order doesn't fall out
naturally, and we have to sort things out in the backend.
Fixes PR28213
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273696 91177308-0d34-0410-b5e6-96231b3b80d8
There are two remaining issues here:
1. No vbptr information
2. Need to mention indirect virtual bases
Getting indirect virtual bases is just a matter of adding an "indirect"
flag, emitting them in the frontend, and ignoring them when appropriate
for DWARF.
All virtual bases use the same artificial vbptr field, so I think the
vbptr offset will be best represented by an implicit __vbptr$ClassName
member similar to our existing __vptr$ member.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273688 91177308-0d34-0410-b5e6-96231b3b80d8
CodeView needs to know if a virtual method was introduced in the current
class, and base classes may not have complete type information, so we
need to thread this bit through from the frontend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273453 91177308-0d34-0410-b5e6-96231b3b80d8
This is the motivating example:
struct B { int b; };
struct A { B *b; };
int f(A *p) { return p->b->b; }
Clang emits complete types for both A and B because they are required to
be complete, but our CodeView emission would only emit forward
declarations of A and B. This was a consequence of the fact that the A*
type must reference the forward declaration of A, which doesn't
reference B at all.
We can't eagerly emit complete definitions of A and B when we request
the forward declaration's type index because of recursive types like
linked lists. If we did that, our stack usage could get out of hand, and
it would be possible to lower a type while attempting to lower a type,
and we would need to double check if our type is already present in the
TypeIndexMap after all recursive getTypeIndex calls.
Instead, defer complete type emission until after all type lowering has
completed. This ensures that all referenced complete types are emitted,
and that type lowering is not re-entrant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273443 91177308-0d34-0410-b5e6-96231b3b80d8
From a design perspective, complete record type emission should not
depend on information from other complete record types.
Currently this map is unused, and needlessly accumulates data throughout
compilation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273431 91177308-0d34-0410-b5e6-96231b3b80d8
We now include namespace scope info in LF_FUNC_ID records and we emit
LF_MFUNC_ID records for member functions as we should.
Class names are now fully qualified, which is what MSVC does.
Add a little bit of scaffolding to handle ThisAdjustment when it arrives
in DISubprogram.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273358 91177308-0d34-0410-b5e6-96231b3b80d8
When you have a map holding a unique_ptr, hold a reference to the raw
pointer instead of the unique pointer. The unique_ptr will be moved on
rehash.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273268 91177308-0d34-0410-b5e6-96231b3b80d8
An incomplete member pointer type will always have a size of zero, so we
don't need an extra flag. Credit to David Majnemer for the idea.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273057 91177308-0d34-0410-b5e6-96231b3b80d8