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