[codeview] Use a type index of zero for static method "this" types

Otherwise VS won't show anything in the autos or watch window of static
methods.

llvm-svn: 313329

[codeview] Fold FIXME into comment, there's nothing to do. NFC

llvm-svn: 313214

[codeview] VLAs and unsized arrays should use a size of zero

Previously we used a size of '1' for VLAs because we weren't sure what
MSVC did. However, MSVC does support declaring an array without a

[codeview] VLAs and unsized arrays should use a size of zero

Previously we used a size of '1' for VLAs because we weren't sure what
MSVC did. However, MSVC does support declaring an array without a size,
for which it emits an array type with a size of zero. Clang emits the
same DI metadata for VLAs and arrays without bound, so we would describe
arrays without bound as having one element. This lead to Microsoft
debuggers only printing a single element.

Emitting a size of zero appears to cause these debuggers to search the
symbol information to find a definition of the variable with accurate
array bounds.

Fixes http://crbug.com/763580

llvm-svn: 313203

show more ...

Mark static member functions as static in CodeViewDebug

Summary:
To improve CodeView quality for static member functions, we need to make the
static explicit. In addition to a small change in LLVM'

Mark static member functions as static in CodeViewDebug

Summary:
To improve CodeView quality for static member functions, we need to make the
static explicit. In addition to a small change in LLVM's CodeViewDebug to
return the appropriate MethodKind, this requires a small change in Clang to
note the staticness in the debug info metadata.

Subscribers: aprantl, hiraditya

Differential Revision: https://reviews.llvm.org/D37715

llvm-svn: 313192

show more ...

[CodeView] Don't output S_UDTs for nested typedefs.

S_UDT records are basically the "bridge" between the debugger's
expression evaluator and the type information. If you type
(Foo*)nullptr into the

[CodeView] Don't output S_UDTs for nested typedefs.

S_UDT records are basically the "bridge" between the debugger's
expression evaluator and the type information. If you type
(Foo*)nullptr into the watch window, the debugger looks for an
S_UDT record named Foo. If it can find one, it displays your type.
Otherwise you get an error.

We have always understood this to mean that if you have code like
this:

struct A {
int X;
};

struct B {
typedef A AT;
AT Member;
};

that you will get 3 S_UDT records. "A", "B", and "B::AT". Because
if you were to type (B::AT*)nullptr into the debugger, it would
need to find an S_UDT record named "B::AT".

But "B::AT" is actually the S_UDT record that would be generated
if B were a namespace, not a struct. So the debugger needs to be
able to distinguish this case. So what it does is:

1. Look for an S_UDT named "B::AT". If it finds one, it knows
that AT is in a namespace.
2. If it doesn't find one, split at the scope resolution operator,
and look for an S_UDT named B. If it finds one, look up the type
for B, and then look for AT as one of its members.

With this algorithm, S_UDT records for nested typedefs are not just
unnecessary, but actually wrong!

The results of implementing this in clang are dramatic. It cuts
our /DEBUG:FASTLINK PDB sizes by more than 50%, and we go from
being ~20% larger than MSVC PDBs on average, to ~40% smaller.

It also slightly speeds up link time. We get about 10% faster
links than without this patch.

Differential Revision: https://reviews.llvm.org/D37410

llvm-svn: 312583

show more ...

Add llvm.codeview.annotation to implement MSVC __annotation

Summary:
This intrinsic represents a label with a list of associated metadata
strings. It is modelled as reading and writing inaccessible

Add llvm.codeview.annotation to implement MSVC __annotation

Summary:
This intrinsic represents a label with a list of associated metadata
strings. It is modelled as reading and writing inaccessible memory so
that it won't be removed as dead code. I think the intention is that the
annotation strings should appear at most once in the debug info, so I
marked it noduplicate. We are allowed to inline code with annotations as
long as we strip the annotation, but that can be done later.

Reviewers: majnemer

Subscribers: eraman, llvm-commits, hiraditya

Differential Revision: https://reviews.llvm.org/D36904

llvm-svn: 312569

show more ...

[codeview] Generalize DIExpression parsing to handle load chains

Summary:
Hopefully this also clarifies exactly when and why we're rewriting
certiain S_LOCALs using reference types: We're using the

[codeview] Generalize DIExpression parsing to handle load chains

Summary:
Hopefully this also clarifies exactly when and why we're rewriting
certiain S_LOCALs using reference types: We're using the reference type
to stand in for a zero-offset load.

Reviewers: inglorion

Subscribers: llvm-commits, hiraditya

Differential Revision: https://reviews.llvm.org/D37309

llvm-svn: 312247

show more ...

[codeview] make DbgVariableLocation::extractFromMachineInstruction use Optional

Summary:
DbgVariableLocation::extractFromMachineInstruction originally
returned a boolean indicating success. This cha

[codeview] make DbgVariableLocation::extractFromMachineInstruction use Optional

Summary:
DbgVariableLocation::extractFromMachineInstruction originally
returned a boolean indicating success. This change makes it return
an Optional<DbgVariableLocation> so we cannot try to access the fields
of the struct if they aren't valid.

Reviewers: aprantl, rnk, zturner

Subscribers: llvm-commits, hiraditya

Differential Revision: https://reviews.llvm.org/D37279

llvm-svn: 312143

show more ...

[NFC] clang-format llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

llvm-svn: 312035

Reland r311957 [codeview] support more DW_OPs for more complete debug info

Summary:
Some variables show up in Visual Studio as "optimized out" even in -O0
-Od builds. This change fixes two issues th

Reland r311957 [codeview] support more DW_OPs for more complete debug info

Summary:
Some variables show up in Visual Studio as "optimized out" even in -O0
-Od builds. This change fixes two issues that would cause this to
happen. The first issue is that not all DIExpressions we generate were
recognized by the CodeView writer. This has been addressed by adding
support for DW_OP_constu, DW_OP_minus, and DW_OP_plus. The second
issue is that we had no way to encode DW_OP_deref in CodeView. We get
around that by changinge the type we encode in the debug info to be
a reference to the type in the source code.

This fixes PR34261.

The reland adds two extra checks to the original: It checks if the
DbgVariableLocation is valid before checking any of its fields, and
it only emits ranges with nonzero registers.

Reviewers: aprantl, rnk, zturner

Reviewed By: rnk

Subscribers: mgorny, llvm-commits, aprantl, hiraditya

Differential Revision: https://reviews.llvm.org/D36907

llvm-svn: 312034

show more ...

Revert "[codeview] support more DW_OPs for more complete debug info"

This reverts commit e160912f53f047bc97e572add179e08e33f4df48.

llvm-svn: 311977

Revert "[codeview] don't try to emit variable locations without registers"

This reverts commit a256fbcacf448ee793d23552c46ed2971bf9eff5.

llvm-svn: 311976

[codeview] don't try to emit variable locations without registers

This fixes a problem introduced 311957, where the compiler would crash
with "fatal error: error in backend: unknown codeview registe

[codeview] don't try to emit variable locations without registers

This fixes a problem introduced 311957, where the compiler would crash
with "fatal error: error in backend: unknown codeview register".

llvm-svn: 311969

show more ...

[codeview] support more DW_OPs for more complete debug info

Summary:
Some variables show up in Visual Studio as "optimized out" even in -O0
-Od builds. This change fixes two issues that would cause

[codeview] support more DW_OPs for more complete debug info

Summary:
Some variables show up in Visual Studio as "optimized out" even in -O0
-Od builds. This change fixes two issues that would cause this to
happen. The first issue is that not all DIExpressions we generate were
recognized by the CodeView writer. This has been addressed by adding
support for DW_OP_constu, DW_OP_minus, and DW_OP_plus. The second
issue is that we had no way to encode DW_OP_deref in CodeView. We get
around that by changinge the type we encode in the debug info to be
a reference to the type in the source code.

This fixes PR34261.

Reviewers: aprantl, rnk, zturner

Reviewed By: rnk

Subscribers: mgorny, llvm-commits, aprantl, hiraditya

Differential Revision: https://reviews.llvm.org/D36907

llvm-svn: 311957

show more ...

[CodeView] Don't output S_UDT symbols for forward decls.

S_UDT symbols are the debugger's "index" for all the structs,
typedefs, classes, and enums in a program. If any of those
structs/classes don

[CodeView] Don't output S_UDT symbols for forward decls.

S_UDT symbols are the debugger's "index" for all the structs,
typedefs, classes, and enums in a program. If any of those
structs/classes don't have a complete declaration, or if there
is a typedef to something that doesn't have a complete definition,
then emitting the S_UDT is unhelpful because it doesn't give
the debugger enough information to do anything useful. On the
other hand, it results in a huge size blow-up in the resulting
PDB, which is exacerbated by an order of magnitude when linking
with /DEBUG:FASTLINK.

With this patch, we drop S_UDT records for types that refer either
directly or indirectly (e.g. through a typedef, pointer, etc) to
a class/struct/union/enum without a complete definition. This
brings us about 50% of the way towards parity with /DEBUG:FASTLINK
PDBs generated from cl-compiled object files.

Differential Revision: https://reviews.llvm.org/D37162

llvm-svn: 311904

show more ...

[codeview] Emit nested enums and typedefs from classes

Previously we limited ourselves to only emitting nested classes, but we
need other kinds of types as well.

This fixes the Visual Studio STL vi

[codeview] Emit nested enums and typedefs from classes

Previously we limited ourselves to only emitting nested classes, but we
need other kinds of types as well.

This fixes the Visual Studio STL visualizers, so that users can
visualize std::string and other objects.

llvm-svn: 310410

show more ...

Remove PrologEpilogInserter's usage of DBG_VALUE's offset field

In the last half-dozen commits to LLVM I removed code that became dead
after removing the offset parameter from llvm.dbg.value gradual

Remove PrologEpilogInserter's usage of DBG_VALUE's offset field

In the last half-dozen commits to LLVM I removed code that became dead
after removing the offset parameter from llvm.dbg.value gradually
proceeding from IR towards the backend. Before I can move on to
DwarfDebug and friends there is one last side-called offset I need to
remove: This patch modifies PrologEpilogInserter's use of the
DBG_VALUE's offset argument to use a DIExpression instead. Because the
PrologEpilogInserter runs at the Machine level I had to play a little
trick with a named llvm.dbg.mir node to get the DIExpressions to print
in MIR dumps (which print the llvm::Module followed by the
MachineFunction dump).

I also had to add rudimentary DwarfExpression support to CodeView and
as a side-effect also fixed a bug (CodeViewDebug::collectVariableInfo
was supposed to give up on variables with complex DIExpressions, but
would fail to do so for fragments, which are also modeled as
DIExpressions).

With this last holdover removed we will have only one canonical way of
representing offsets to debug locations which will simplify the code
in DwarfDebug (and future versions of CodeViewDebug once it starts
handling more complex expressions) and make it easier to reason about.

This patch is NFC-ish: All test case changes are for assembler
comments and the binary output does not change.

rdar://problem/33580047
Differential Revision: https://reviews.llvm.org/D36125

llvm-svn: 309751

show more ...

[codeview] Ignore DBG_VALUEs when choosing a BB start source loc

When the first instruction of a basic block has no location (consider a
LEA materializing the address of an alloca for a call), we wa

[codeview] Ignore DBG_VALUEs when choosing a BB start source loc

When the first instruction of a basic block has no location (consider a
LEA materializing the address of an alloca for a call), we want to start
the line table for the block with the first valid source location in the
block. We need to ignore DBG_VALUE instructions during this scan to get
decent line tables.

llvm-svn: 309628

show more ...

[codeview] Emit 'D' as the cv source language for D code

This matches DMD:
https://github.com/dlang/dmd/blob/522263965cf3a27ed16b31f3c3562db86cdeabec/src/ddmd/backend/cv8.c#L199

Fixes PR33899.

llv

[codeview] Emit 'D' as the cv source language for D code

This matches DMD:
https://github.com/dlang/dmd/blob/522263965cf3a27ed16b31f3c3562db86cdeabec/src/ddmd/backend/cv8.c#L199

Fixes PR33899.

llvm-svn: 308890

show more ...

Format some case labels and shrink an anonymous namespace NFC

llvm-svn: 308889

[COFF, ARM64, CodeView] Add support to emit CodeView debug info for ARM64 COFF

Reviewers: compnerd, ruiu, rnk, zturner

Reviewed By: rnk

Subscribers: majnemer, aemerson, aprantl, javed.absar, krist

[COFF, ARM64, CodeView] Add support to emit CodeView debug info for ARM64 COFF

Reviewers: compnerd, ruiu, rnk, zturner

Reviewed By: rnk

Subscribers: majnemer, aemerson, aprantl, javed.absar, kristof.beyls, llvm-commits

Differential Revision: https://reviews.llvm.org/D35518

llvm-svn: 308665

show more ...

[codeview] Use the first valid source location at the top of every MBB

If the instructions at the beginning of the block have no location,
we're better off using the location of the first instructio

[codeview] Use the first valid source location at the top of every MBB

If the instructions at the beginning of the block have no location,
we're better off using the location of the first instruction in the
current basic block. At the very least, that instruction post-dominates
this one, whereas if we don't emit a .cv_loc directive, we end up using
the potentially invalid location that falls through from the previous
block.

We could probably do better here by emitting some kind of ".cv_loc end"
directive that stops the line table entry of the previous .cv_loc
directive from bleeding out of its basic block. This would improve the
line table when an entire MBB has no valid location info.

llvm-svn: 306889

show more ...

Move Object format code to lib/BinaryFormat.

This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various type

Move Object format code to lib/BinaryFormat.

This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.

Differential Revision: https://reviews.llvm.org/D33843

llvm-svn: 304864

show more ...

[CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 304839

[CodeView] Rename ModuleDebugFragment -> DebugSubsection.

This is more concise, and matches the terminology used in other
parts of the codebase more closely.

llvm-svn: 304218