Better support for POSIX paths in PDBs.

This a resubmission of a patch which was previously reverted
due to breaking several lld tests. The issues causing those
failures have been fixed, so the pat

Better support for POSIX paths in PDBs.

This a resubmission of a patch which was previously reverted
due to breaking several lld tests. The issues causing those
failures have been fixed, so the patch is now resubmitted.

---Original Commit Message---

While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.

The tools need to be able to handle this, because certain types
of debugging scenarios are possible without a running process
and so don't necessarily require you to be on a Windows system.
These include post-mortem debugging and binary forensics (e.g.
using a debugger to disassemble functions and examine symbols
without running the process).

There's changes in clang, LLD, and lldb in this patch. After
this the cross-platform disassembly and source-list tests pass
on Linux.

Furthermore, the behavior of LLD can now be summarized by a much
simpler rule than before: Unless you specify /pdbsourcepath and
/pdbaltpath, the PDB ends up with paths that are valid within
the context of the machine that the link is performed on.

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

llvm-svn: 344377

show more ...

Revert SymbolFileNativePDB plugin.

This was originally causing some test failures on non-Windows
platforms, which required fixes in the compiler and linker. After
those fixes, however, other tests

Revert SymbolFileNativePDB plugin.

This was originally causing some test failures on non-Windows
platforms, which required fixes in the compiler and linker. After
those fixes, however, other tests started failing. Reverting
temporarily until I can address everything.

llvm-svn: 344279

show more ...

Better support for POSIX paths in PDBs.

While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.

The tools need to

Better support for POSIX paths in PDBs.

While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.

The tools need to be able to handle this, because certain types
of debugging scenarios are possible without a running process
and so don't necessarily require you to be on a Windows system.
These include post-mortem debugging and binary forensics (e.g.
using a debugger to disassemble functions and examine symbols
without running the process).

There's changes in clang, LLD, and lldb in this patch. After
this the cross-platform disassembly and source-list tests pass
on Linux.

Furthermore, the behavior of LLD can now be summarized by a much
simpler rule than before: Unless you specify /pdbsourcepath and
/pdbaltpath, the PDB ends up with paths that are valid within
the context of the machine that the link is performed on.

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

llvm-svn: 344269

show more ...

[CodeView] Only add the Scoped flag for an enum type when it has an immediate function scope to match MSVC

Reviewers: rnk, zturner, llvm-commits

Reviewed By: rnk

Differential Revision: https://rev

[CodeView] Only add the Scoped flag for an enum type when it has an immediate function scope to match MSVC

Reviewers: rnk, zturner, llvm-commits

Reviewed By: rnk

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

llvm-svn: 343627

show more ...

[CodeView] Emit function options for subprogram and member functions

Summary:
Use the newly added DebugInfo (DI) Trivial flag, which indicates if a C++ record is trivial or not, to determine Codevie

[CodeView] Emit function options for subprogram and member functions

Summary:
Use the newly added DebugInfo (DI) Trivial flag, which indicates if a C++ record is trivial or not, to determine Codeview::FunctionOptions.

Clang and MSVC generate slightly different Codeview for C++ records. For example, here is the C++ code for a class with a defaulted ctor,

class C {
public:
C() = default;
};

Clang will produce a LF for the defaulted ctor while MSVC does not. For more details, refer to FIXMEs in the test cases in "function-options.ll" included with this set of changes.


Reviewers: zturner, rnk, llvm-commits, aleksandr.urakov

Reviewed By: rnk

Subscribers: Hui, JDevlieghere

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

llvm-svn: 343626

show more ...

[codeview] Fix 32-bit x86 variable locations in realigned stack frames

Add the .cv_fpo_stackalign directive so that we can define $T0, or the
VFRAME virtual register, with it. This was overlooked in

[codeview] Fix 32-bit x86 variable locations in realigned stack frames

Add the .cv_fpo_stackalign directive so that we can define $T0, or the
VFRAME virtual register, with it. This was overlooked in the initial
implementation because unlike MSVC, we push CSRs before allocating stack
space, so this value is only needed to describe local variable
locations. Variables that the compiler now addresses via ESP are instead
described as being stored at offsets from VFRAME, which for us is ESP
after alignment in the prologue.

This adds tests that show that we use the VFRAME register properly in
our S_DEFRANGE records, and that we emit the correct FPO data to define
it.

Fixes PR38857

llvm-svn: 343603

show more ...

[codeview] Simplify S_DEFRANGE emission code, NFC

These assembler directives are still pretty unreadable and it would be
nice to clean them up at some point.

llvm-svn: 343544

[codeview] Emit S_FRAMEPROC and use S_DEFRANGE_FRAMEPOINTER_REL

Summary:
Before this change, LLVM would always describe locals on the stack as
being relative to some specific register, RSP, ESP, EBP

[codeview] Emit S_FRAMEPROC and use S_DEFRANGE_FRAMEPOINTER_REL

Summary:
Before this change, LLVM would always describe locals on the stack as
being relative to some specific register, RSP, ESP, EBP, ESI, etc.
Variables in stack memory are pretty common, so there is a special
S_DEFRANGE_FRAMEPOINTER_REL symbol for them. This change uses it to
reduce the size of our debug info.

On top of the size savings, there are cases on 32-bit x86 where local
variables are addressed from ESP, but ESP changes across the function.
Unlike in DWARF, there is no FPO data to describe the stack adjustments
made to push arguments onto the stack and pop them off after the call,
which makes it hard for the debugger to find the local variables in
frames further up the stack.

To handle this, CodeView has a special VFRAME register, which
corresponds to the $T0 variable set by our FPO data in 32-bit. Offsets
to local variables are instead relative to this value.

This is part of PR38857.

Reviewers: hans, zturner, javed.absar

Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits

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

llvm-svn: 343543

show more ...

llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)

Summary: The convenience wrapper in STLExtras is available since rL342102.

Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb

Subscr

llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)

Summary: The convenience wrapper in STLExtras is available since rL342102.

Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb

Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits

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

llvm-svn: 343163

show more ...

[codeview] Remove dead code

llvm-svn: 342285

[DebugInfo] Do not generate label debug info if it has been processed.

In DwarfDebug::collectEntityInfo(), if the label entity is processed in
DbgLabels list, it means the label is not optimized out

[DebugInfo] Do not generate label debug info if it has been processed.

In DwarfDebug::collectEntityInfo(), if the label entity is processed in
DbgLabels list, it means the label is not optimized out. There is no
need to generate debug info for it with null position.

llvm-svn: 341513

show more ...

[CodeView] Omit forward references for unnamed structs and unions

Codeview references to unnamed structs and unions are expected to refer to the
complete type definition instead of a forward referen

[CodeView] Omit forward references for unnamed structs and unions

Codeview references to unnamed structs and unions are expected to refer to the
complete type definition instead of a forward reference so Visual Studio can
resolve the type properly.

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

llvm-svn: 334382

show more ...

Resubmit [pdb] Change /DEBUG:GHASH to emit 8 byte hashes."

This fixes the remaining failing tests, so resubmitting with no
functional change.

llvm-svn: 332676

Revert "[pdb] Change /DEBUG:GHASH to emit 8 byte hashes."

A few tests haven't been properly updated, so reverting while
I have time to investigate proper fixes.

llvm-svn: 332672

[pdb] Change /DEBUG:GHASH to emit 8 byte hashes.

Previously we emitted 20-byte SHA1 hashes. This is overkill
for identifying debug info records, and has the negative side
effect of making object fi

[pdb] Change /DEBUG:GHASH to emit 8 byte hashes.

Previously we emitted 20-byte SHA1 hashes. This is overkill
for identifying debug info records, and has the negative side
effect of making object files bigger and links slower. By
using only the last 8 bytes of a SHA1, we get smaller object
files and ~10% faster links.

This modifies the format of the .debug$H section by adding a new
value for the hash algorithm field, so that the linker will still
work when its object files have an old format.

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

llvm-svn: 332669

show more ...

[CodeView] Improve debugging of virtual base class member variables

Initial support for passing the virtual base pointer offset to CodeViewDebug.

https://reviews.llvm.org/D46271

llvm-svn: 332296

[DebugInfo] Examine all uses of isDebugValue() for debug instructions.

Because we create a new kind of debug instruction, DBG_LABEL, we need to
check all passes which use isDebugValue() to check Mac

[DebugInfo] Examine all uses of isDebugValue() for debug instructions.

Because we create a new kind of debug instruction, DBG_LABEL, we need to
check all passes which use isDebugValue() to check MachineInstr is debug
instruction or not. When expelling debug instructions, we should expel
both DBG_VALUE and DBG_LABEL. So, I create a new function,
isDebugInstr(), in MachineInstr to check whether the MachineInstr is
debug instruction or not.

This patch has no new test case. I have run regression test and there is
no difference in regression test.

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

Patch by Hsiangkai Wang.

llvm-svn: 331844

show more ...

[CodeView] Initial support for emitting S_THUNK32 symbols for compiler...

When emitting CodeView debug information, compiler-generated thunk routines
should be emitted using S_THUNK32 symbols instea

[CodeView] Initial support for emitting S_THUNK32 symbols for compiler...

When emitting CodeView debug information, compiler-generated thunk routines
should be emitted using S_THUNK32 symbols instead of S_GPROC32_ID symbols so
Visual Studio can properly step into the user code. This initial support only
handles standard thunk ordinals.

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

llvm-svn: 330132

show more ...

CodeGen: Don't try to canonicalize Unix-style paths in CodeView debug info.

Most importantly, we should not replace slashes with backslashes
because that would invalidate the path.

Differential Rev

CodeGen: Don't try to canonicalize Unix-style paths in CodeView debug info.

Most importantly, we should not replace slashes with backslashes
because that would invalidate the path.

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

llvm-svn: 329838

show more ...

[Debuginfo][COFF] Minimal serialization support for precompiled types records

This change adds support for the LF_PRECOMP and LF_ENDPRECOMP records required
to read/write Microsoft precompiled types

[Debuginfo][COFF] Minimal serialization support for precompiled types records

This change adds support for the LF_PRECOMP and LF_ENDPRECOMP records required
to read/write Microsoft precompiled types .objs.
See https://en.wikipedia.org/wiki/Precompiled_header#Microsoft_Visual_C_and_C++

This also adds handling for the .debug$P section, which is actually a .debug$T
section in disguise, found only in precompiled .objs.

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

llvm-svn: 329613

show more ...

[CodeGen] Change std::sort to llvm::sort in response to r327219

Summary:
r327219 added wrappers to std::sort which randomly shuffle the container before sorting.
This will help in uncovering non-det

[CodeGen] Change std::sort to llvm::sort in response to r327219

Summary:
r327219 added wrappers to std::sort which randomly shuffle the container before sorting.
This will help in uncovering non-determinism caused due to undefined sorting
order of objects having the same key.

To make use of that infrastructure we need to invoke llvm::sort instead of std::sort.

Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort.
Refer the comments section in D44363 for a list of all the required patches.

Reviewers: bogner, rnk, MatzeB, RKSimon

Reviewed By: rnk

Subscribers: JDevlieghere, javed.absar, llvm-commits

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

llvm-svn: 329435

show more ...

Move TargetLoweringObjectFile from CodeGen to Target to fix layering

It's implemented in Target & include from other Target headers, so the
header should be in Target.

llvm-svn: 328392

Re-land r327620 "[CodeView] Initial support for emitting S_BLOCK32 symbols for lexical scopes"

This is safe to land now that we don't copy FunctionInfo when rehashing
the DenseMap.

llvm-svn: 327670

[codeview] Fix sense of the assertion about hashtable insertion

llvm-svn: 327669

[codeview] Delete FunctionInfo copy ctor and move out of DenseMap

We were unnecessarily copying a bunch of these FunctionInfo objects
around when rehashing the DenseMap.

Furthermore, r327620 introd

[codeview] Delete FunctionInfo copy ctor and move out of DenseMap

We were unnecessarily copying a bunch of these FunctionInfo objects
around when rehashing the DenseMap.

Furthermore, r327620 introduced pointers referring to objects owned by
FunctionInfo, and the default copy ctor did the wrong thing in this
case, leading to use-after-free when the DenseMap gets rehashed.

I will rebase r327620 on this next and recommit it.

llvm-svn: 327665

show more ...