[MC] De-capitalize SwitchSection. NFC

Add SwitchSection to return switchSection. The API will be removed soon.

[MC] De-capitalize MCStreamer functions

Follow-up to c031378ce01b8485ba0ef486654bc9393c4ac024 .
The class is mostly consistent now.

[MC] Lower case the first letter of EmitCOFF* EmitWin* EmitCV*. NFC

[CodeView] Combine variable def ranges that are continuous.

It saves about 1.13% size for chrome.dll.pdb on chrome official build.

Reviewed By: rnk

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

[CodeView] Combine variable def ranges that are continuous.

It saves about 1.13% size for chrome.dll.pdb on chrome official build.

Reviewed By: rnk

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

show more ...

Reland "[dwarf] Emit a DIGlobalVariable for constant strings."

An upcoming patch will extend llvm-symbolizer to provide the source line
information for global variables. The goal is to move AddressS

Reland "[dwarf] Emit a DIGlobalVariable for constant strings."

An upcoming patch will extend llvm-symbolizer to provide the source line
information for global variables. The goal is to move AddressSanitizer
off of internal debug info for symbolization onto the DWARF standard
(and doing a clean-up in the process). Currently, ASan reports the line
information for constant strings if a memory safety bug happens around
them. We want to keep this behaviour, so we need to emit debuginfo for
these variables as well.

Reviewed By: dblaikie, rnk, aprantl

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

show more ...

Revert "[dwarf] Emit a DIGlobalVariable for constant strings."

This reverts commit 4680982b36a84770a1600fc438be8ec090671724.

Broke a fuchsia windows bot. More details in the review:
https://reviews

Revert "[dwarf] Emit a DIGlobalVariable for constant strings."

This reverts commit 4680982b36a84770a1600fc438be8ec090671724.

Broke a fuchsia windows bot. More details in the review:
https://reviews.llvm.org/D123534

show more ...

[dwarf] Emit a DIGlobalVariable for constant strings.

An upcoming patch will extend llvm-symbolizer to provide the source line
information for global variables. The goal is to move AddressSanitizer

[dwarf] Emit a DIGlobalVariable for constant strings.

An upcoming patch will extend llvm-symbolizer to provide the source line
information for global variables. The goal is to move AddressSanitizer
off of internal debug info for symbolization onto the DWARF standard
(and doing a clean-up in the process). Currently, ASan reports the line
information for constant strings if a memory safety bug happens around
them. We want to keep this behaviour, so we need to emit debuginfo for
these variables as well.

Reviewed By: dblaikie, rnk, aprantl

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

show more ...

MachineModuleInfo: Don't allow dynamically setting DbgInfoAvailable

This can be set up front, and used only as a cache. This avoids a
field that looks like it requires MIR serialization.

I believe

MachineModuleInfo: Don't allow dynamically setting DbgInfoAvailable

This can be set up front, and used only as a cache. This avoids a
field that looks like it requires MIR serialization.

I believe this fixes 2 bugs for CodeView. First, this addresses a
FIXME that the flag -diable-debug-info-print only works with
DWARF. Second, it fixes emitting debug info with emissionKind NoDebug.

show more ...

[CodeGen] Apply clang-tidy fixes for readability-redundant-smartptr-get (NFC)

Cleanup includes: DebugInfo & CodeGen

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121332

[PDB] Add char8_t type

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

[CodeView] Avoid integer overflow while parsing long version strings

This came up on a funny vendor-provided version string that didn't have
a standard dotted quad of numbers.

[clang-cl] Support the /HOTPATCH flag

This patch adds support for the MSVC /HOTPATCH flag: https://docs.microsoft.com/sv-se/cpp/build/reference/hotpatch-create-hotpatchable-image?view=msvc-170&viewF

[clang-cl] Support the /HOTPATCH flag

This patch adds support for the MSVC /HOTPATCH flag: https://docs.microsoft.com/sv-se/cpp/build/reference/hotpatch-create-hotpatchable-image?view=msvc-170&viewFallbackFrom=vs-2019

The flag is translated to a new -fms-hotpatch flag, which in turn adds a 'patchable-function' attribute for each function in the TU. This is then picked up by the PatchableFunction pass which would generate a TargetOpcode::PATCHABLE_OP of minsize = 2 (which means the target instruction must resolve to at least two bytes). TargetOpcode::PATCHABLE_OP is only implemented for x86/x64. When targetting ARM/ARM64, /HOTPATCH isn't required (instructions are always 2/4 bytes and suitable for hotpatching).

Additionally, when using /Z7, we generate a 'hot patchable' flag in the CodeView debug stream, in the S_COMPILE3 record. This flag is then picked up by LLD (or link.exe) and is used in conjunction with the linker /FUNCTIONPADMIN flag to generate extra space before each function, to accommodate for live patching long jumps. Please see: https://github.com/llvm/llvm-project/blob/d703b922961e0d02a5effdd4bfbb23ad50a3cc9f/lld/COFF/Writer.cpp#L1298

The outcome is that we can finally use Live++ or Recode along with clang-cl.

NOTE: It seems that MSVC cl.exe always enables /HOTPATCH on x64 by default, although if we did the same I thought we might generate sub-optimal code (if this flag was active by default). Additionally, MSVC always generates a .debug$S section and a S_COMPILE3 record, which Clang doesn't do without /Z7. Therefore, the following MSVC command-line "cl /c file.cpp" would have to be written with Clang such as "clang-cl /c file.cpp /HOTPATCH /Z7" in order to obtain the same result.

Depends on D43002, D80833 and D81301 for the full feature.

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

show more ...

Re-land [CodeView] Add full repro to LF_BUILDINFO record

This patch writes the full -cc1 command into the resulting .OBJ, like MSVC does. This allows for external tools (Recode, Live++) to rebuild a

Re-land [CodeView] Add full repro to LF_BUILDINFO record

This patch writes the full -cc1 command into the resulting .OBJ, like MSVC does. This allows for external tools (Recode, Live++) to rebuild a source file without any external dependency but the .OBJ itself (other than the compiler) and without knowledge of the build system.

The LF_BUILDINFO record stores a full path to the compiler, the PWD (CWD at program startup), a relative or absolute path to the source, and the full CC1 command line. The stored command line is self-standing (does not depend on the environment). In the same way, MSVC doesn't exactly store the provided command-line, but an expanded version (a somehow equivalent of CC1) which is also self-standing.

For more information see PR36198 and D43002.

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

show more ...

Add Rust to CodeView SourceLanguage (CV_CFL_LANG) enum

Microsoft has added several new entries to the CV_CFL_LANG enum, including Rust:
https://docs.microsoft.com/en-us/visualstudio/debugger/deb

Add Rust to CodeView SourceLanguage (CV_CFL_LANG) enum

Microsoft has added several new entries to the CV_CFL_LANG enum, including Rust:
https://docs.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/cv-cfl-lang

This change adds Rust to the corresponding LLVM enum and translates `dwarf::DW_LANG_Rust` to `SourceLanguage::Rust` in the CodeView AsmPrinter.

This means that Rust will no longer emit as Masm.

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

show more ...

[CodeView] Clamp Frontend version

D43002 introduced a test debug-info-objname.cpp that outputted the current compiler version into CodeView. Internally we appended a date to the patch version and ov

[CodeView] Clamp Frontend version

D43002 introduced a test debug-info-objname.cpp that outputted the current compiler version into CodeView. Internally we appended a date to the patch version and overflowed the 16-bits allocated to that space. This change clamps the Frontend version outputted values to 16-bits like rGd1185fc081ead71a8bf239ff1814f5ff73084c15 did for the Backend version.

Testing:
ninja check-all
newly added tests correctly clamps and no longer asserts when trying to output the field

Reviewed By: aganea

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

show more ...

Reland - [CodeView] Emit S_OBJNAME record

Reland integrates build fixes & further review suggestions.

Thanks to @zturner for the initial S_OBJNAME patch!

Differential Revision: https://reviews.llv

Reland - [CodeView] Emit S_OBJNAME record

Reland integrates build fixes & further review suggestions.

Thanks to @zturner for the initial S_OBJNAME patch!

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

show more ...

Revert [CodeView] Emit S_OBJNAME record

Also revert all subsequent fixes:
- abd1cbf5e543f0f114d2742e109ead7d7ddbf9c4 [Clang] Disable debug-info-objname.cpp test on Unix until I sort out the issue.
-

Revert [CodeView] Emit S_OBJNAME record

Also revert all subsequent fixes:
- abd1cbf5e543f0f114d2742e109ead7d7ddbf9c4 [Clang] Disable debug-info-objname.cpp test on Unix until I sort out the issue.
- 00ec441253048f5e30540ea26bb0a28c42a5fc18 [Clang] debug-info-objname.cpp test: explictly encode a x86 target when using %clang_cl to avoid falling back to a native CPU triple.
- cd407f6e52b09cce2bef24c74b7f36fedc94991b [Clang] Fix build by restricting debug-info-objname.cpp test to x86.

show more ...

[CodeView] Emit S_OBJNAME record

Thanks to @zturner for the initial patch!

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

[NFC][CodeView] Use one unified access to the module in beginModule.

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

[CodeView] Properly handle a DISubprogram in getScopeIndex.

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

[CodeView] Fortran debug info emission in Code View.

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

DebugInfo: Use clang's preferred names for integer types

This reverts c7f16ab3e3f27d944db72908c9c1b1b7366f5515 / r109694 - which
suggested this was done to improve consistency with the gdb test suit

DebugInfo: Use clang's preferred names for integer types

This reverts c7f16ab3e3f27d944db72908c9c1b1b7366f5515 / 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

show more ...

[CodeView] Recognize Fortran95 as Fortran instead of MASM

Map Fortran95 sources to Fortran so the CodeView language is not emitted as
MASM.

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

[CodeView] Saturate values bigger than supported by APInt.

This fixes an assert firing when compiling code which involves 128 bit
integrals.

This would trigger runtime checks similar to this:
```
A

[CodeView] Saturate values bigger than supported by APInt.

This fixes an assert firing when compiling code which involves 128 bit
integrals.

This would trigger runtime checks similar to this:
```
Assertion failed: getMinSignedBits() <= 64 && "Too many bits for int64_t", file llvm/include/llvm/ADT/APInt.h, line 1646
```

To get around this, we just saturate those big values.

Reviewed By: rnk

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

show more ...