History log of /llvm-project/llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp (Results 51 – 75 of 409)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 9ee15bba 26-May-2022 Fangrui Song <i@maskray.me>

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


Revision tags: llvmorg-14.0.4
# 98860462 16-May-2022 Zequan Wu <zequanwu@google.com>

[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 ...


# 7aa1fa0a 18-May-2022 Mitch Phillips <31459023+hctim@users.noreply.github.com>

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 ...


# ed2c3218 17-May-2022 Mitch Phillips <31459023+hctim@users.noreply.github.com>

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 ...


# 4680982b 16-May-2022 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[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 ...


Revision tags: llvmorg-14.0.3, llvmorg-14.0.2
# 9592e88f 17-Apr-2022 Matt Arsenault <Matthew.Arsenault@amd.com>

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 ...


Revision tags: llvmorg-14.0.1
# 1eada2ad 21-Mar-2022 Kazu Hirata <kazu@google.com>

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


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3
# ed98c1b3 09-Mar-2022 serge-sans-paille <sguelton@redhat.com>

Cleanup includes: DebugInfo & CodeGen

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


Revision tags: llvmorg-14.0.0-rc2
# 5c9e20d7 01-Mar-2022 Zequan Wu <zequanwu@google.com>

[PDB] Add char8_t type

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


# 64037afe 10-Feb-2022 Reid Kleckner <rnk@google.com>

[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.


Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3
# 5af2433e 20-Jan-2022 Alexandre Ganea <alexandre.ganea@legionlabs.com>

[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 ...


# aba5b91b 20-Jan-2022 Alexandre Ganea <alexandre.ganea@legionlabs.com>

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 ...


Revision tags: llvmorg-13.0.1-rc2
# 3d10997e 06-Jan-2022 Arlo Siemsen <arsiem@microsoft.com>

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 ...


# ba51d26e 28-Dec-2021 modimo <modimo@fb.com>

[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 ...


# a282ea48 21-Dec-2021 Alexandre Ganea <alexandre.ganea@legionlabs.com>

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 ...


# 5bb5142e 21-Dec-2021 Alexandre Ganea <alexandre.ganea@legionlabs.com>

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 ...


# f44e3fba 21-Dec-2021 Alexandre Ganea <alexandre.ganea@legionlabs.com>

[CodeView] Emit S_OBJNAME record

Thanks to @zturner for the initial patch!

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


# b5c42ef3 07-Dec-2021 Chih-Ping Chen <chih-ping.chen@intel.com>

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

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


Revision tags: llvmorg-13.0.1-rc1
# cf0e32d1 03-Nov-2021 Chih-Ping Chen <chih-ping.chen@intel.com>

[CodeView] Properly handle a DISubprogram in getScopeIndex.

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


# 2ed29d87 29-Oct-2021 Chih-Ping Chen <chih-ping.chen@intel.com>

[CodeView] Fortran debug info emission in Code View.

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


# f6a561c4 24-Sep-2021 David Blaikie <dblaikie@gmail.com>

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 ...


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4
# bafd8b1a 22-Sep-2021 Brock Wyma <brock.wyma@intel.com>

[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


Revision tags: llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init
# f84c70a3 01-Jul-2021 Matheus Izvekov <mizvekov@gmail.com>

[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 ...


Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1
# 61484762 11-May-2021 Chen Zheng <czhengsz@cn.ibm.com>

[Debug-Info] change Tag type to dwarf::Tag for createAndAddDIE; NFC

Reviewed By: dblaikie

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


# 77357208 21-Apr-2021 Michael Holman <michael.holman@microsoft.com>

[CodeView] Add CodeView support for PGO debug information

This change adds debug information about whether PGO is being used or
not.

Microsoft performance tooling (e.g. xperf, WPA) uses this inform

[CodeView] Add CodeView support for PGO debug information

This change adds debug information about whether PGO is being used or
not.

Microsoft performance tooling (e.g. xperf, WPA) uses this information to
show whether functions are optimized with PGO or not, as well as whether
PGO information is invalid.

This information is useful for validating whether training scenarios are
providing good coverage of real world scenarios, showing if profile data
is out of date, etc.

Reviewed By: rnk

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

show more ...


12345678910>>...17