aganea wrote:
Thanks for the answer.
Are these new flags `-fms-hotpatch-functions-file=` and
`-fms-hotpatch-functions-list=` populated with data maintained manually by the
Windows developpers?
If I understand correctly, what you describe as "symbols that were hot-patched"
means functions tha
aganea wrote:
Oh so all this dance (`_ref_` and the additional metadata) is for code page
integrity purposes? To keep them unmodified in memory? So how does then the
kernel use the PE metadata if it doesn't patch the code memory pages of the
initial (running) image? Is there an additional mech
@@ -0,0 +1,20 @@
+// This verifies that hotpatch function attributes are correctly propagated
when compiling directly to OBJ.
+//
+// RUN: %clang_cl -c --target=x86_64-windows-msvc -O2 /Z7
-fms-hotpatch-functions-file=%S/ms-hotpatch-functions.txt /Fo%t.obj %s
ag
@@ -453,6 +453,37 @@ CodeGenModule::CodeGenModule(ASTContext &C,
if (Context.getTargetInfo().getTriple().getArch() == llvm::Triple::x86)
getModule().addModuleFlag(llvm::Module::Error, "NumRegisterParameters",
CodeGenOpts.NumRegisterParameters
@@ -176,6 +176,21 @@ class CallerSym : public SymbolRecord {
uint32_t RecordOffset = 0;
};
+class HotPatchFuncSym : public SymbolRecord {
aganea wrote:
Thanks! Would that tooling remain proprietary, or is it something that will be
open-sourced as well, for
@@ -0,0 +1,20 @@
+// This verifies that hotpatch function attributes are correctly propagated
when compiling directly to OBJ.
+//
+// RUN: %clang_cl -c --target=x86_64-windows-msvc -O2 /Z7
-fms-hotpatch-functions-file=%S/ms-hotpatch-functions.txt /Fo%t.obj %s
ag
@@ -807,6 +809,32 @@ void CodeViewDebug::emitObjName() {
endSymbolRecord(CompilerEnd);
}
+void CodeViewDebug::emitHotPatchInformation() {
aganea wrote:
As mentionned before, maybe better to rename to
`emitSecureHotPatchInformation()`
https://github.com/ll
@@ -0,0 +1,242 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,18 @@
+// This verifies that hotpatch function attributes are correctly propagated
through LLVM IR when compiling with LTO.
+//
+// RUN: %clang_cl -c --target=x86_64-windows-msvc -O2 /Z7
-fms-hotpatch-functions-file=%S/ms-hotpatch-functions.txt -flto /Fo%t.bc %s
-
@@ -453,6 +453,37 @@ CodeGenModule::CodeGenModule(ASTContext &C,
if (Context.getTargetInfo().getTriple().getArch() == llvm::Triple::x86)
getModule().addModuleFlag(llvm::Module::Error, "NumRegisterParameters",
CodeGenOpts.NumRegisterParameters
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -250,6 +250,7 @@ add_llvm_component_library(LLVMCodeGen
VirtRegMap.cpp
WasmEHPrepare.cpp
WindowScheduler.cpp
+ WindowsHotPatch.cpp
aganea wrote:
Similarily, `WindowsSecureHotPatch.cpp`?
https://github.com/llvm/llvm-project/pull/138972
__
@@ -6946,6 +6946,16 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
Args.AddLastArg(CmdArgs, options::OPT_fms_hotpatch);
+ if (Arg *A = Args.getLastArg(options::OPT_fms_hotpatch_functions_file)) {
aganea wrote:
Idem, extra brace.
https:
@@ -0,0 +1,283 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/aganea approved this pull request.
LGTM. Perhaps you might want to wait a few days before commiting, in case
others would like to comment.
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lis
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea commented:
The patch looks good to me, but I have one last question:
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,283 @@
+//===-- WindowsHotPatch.cpp - Support for Windows hotpatching
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/138972
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aganea wrote:
> Both the original patch and the redo break the [Solaris/amd64
> buildbot](https://lab.llvm.org/staging/#/builders/120/builds/9897). I wonder
> if somehow the fact that the source lives in `/opt/llvm-buildbot` somehow
> interferes with Windows command line parsing?
Yes, the fil
aganea wrote:
> In this version, Clang emits a full debug IR, but if we're going to do this
> by default, it probably makes more sense to emit just a minimal `llvm.dbg.cu`
> when debug info isn’t otherwise enabled. I’ve already experimented with that
> approach.
Yes, I think one of my worry re
aganea wrote:
> Is there a way I could have detected this during my local builds, before
> submitting a PR?
I assume checking out the repo on a Linux box under /opt/… and running the
tests would yield the same issue, but I haven’t tried it.
https://github.com/llvm/llvm-project/pull/145565
___
aganea wrote:
> I just tried building and running tests under Ubuntu 24.04. The tests passed,
> i.e. they didn't hit the same problem. So I don't have an easy way to verify
> a fix.
I recall on MacOS the issue happens in a /Users/ folder (with this exact
casing). Are you able to move the chec
aganea wrote:
> #145737 for fix.
>
> I tried moving my checkout dir to `/Users`, but this had no effect on the
> tests.
@nico might know a repro perhaps.
https://github.com/llvm/llvm-project/pull/145565
___
cfe-commits mailing list
cfe-commits@lists
aganea wrote:
> #145737 for fix.
>
> I tried moving my checkout dir to `/Users`, but this had no effect on the
> tests.
You can also check the test command lines and the outputs by running a single
test in a more verbose more, such as:
```
> py {build_folder}/bin/llvm-lit.py -a -vv
> clang/t
aganea wrote:
MSVC emits this debug section at all times (S_OBJNAME and S_COMPILE3). Can't we
do the same without checking for the `getModuleFlag("ms-hotpatch")` flag?
https://github.com/llvm/llvm-project/pull/142970
___
cfe-commits mailing list
cfe-c
aganea wrote:
The other a bit related point to this, is perhaps we should re-evaluate
enabling `/HOTPATCH` at all times on x64 targets, like MSVC.
https://github.com/llvm/llvm-project/pull/142970
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
https://github.com/aganea commented:
This PR will all depend on the course taken on
https://github.com/llvm/llvm-project/pull/142970
https://github.com/llvm/llvm-project/pull/142969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
@@ -0,0 +1,57 @@
+; RUN: llc -filetype=obj -o - %s | llvm-readobj --codeview - | FileCheck %s
+
+; ModuleID = 'a.c'
+source_filename = "a.c"
+target datalayout =
"e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-win
https://github.com/aganea edited
https://github.com/llvm/llvm-project/pull/142969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -560,11 +560,12 @@ bool AsmPrinter::doInitialization(Module &M) {
}
if (MAI->doesSupportDebugInformation()) {
-bool EmitCodeView = M.getCodeViewFlag();
-if (EmitCodeView &&
-(TM.getTargetTriple().isOSWindows() || TM.getTargetTriple().isUEFI()))
+// O
@@ -613,19 +613,30 @@ static SourceLanguage MapDWLangToCVLang(unsigned DWLang) {
void CodeViewDebug::beginModule(Module *M) {
// If module doesn't have named metadata anchors or COFF debug section
aganea wrote:
Adjust comment.
https://github.com/llvm/llvm-pr
@@ -98,6 +98,9 @@ class LLVM_LIBRARY_VISIBILITY CodeViewDebug : public
DebugHandlerBase {
/// The codeview CPU type used by the translation unit.
codeview::CPUType TheCPU;
+ /// Whether to emit compiler information only.
+ bool NoDebug = false;
aganea w
aganea wrote:
> Would it be sufficient to change the `/Fo...` argument to `-Fo...` ?
You actually have to add hyphens before %s in the tests, such as:
`// RUN: not %clang_cl -c --target=x86_64-windows-msvc -O2 /Z7
-fms-secure-hotpatch-functions-file=%S/this-file-is-intentionally-missing-do-not
https://github.com/aganea approved this pull request.
https://github.com/llvm/llvm-project/pull/145737
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
201 - 240 of 240 matches
Mail list logo
