viewing diff: dotnet/main -> llvm/release/14.x #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… new --mono-api-version option which returns a numerical version which is used by mono to detect which version of the mono llvm fork it is compiled with.
…hose associated stack slot index will be saved in MachineFunction, and later can be saved in the mono specific EH tables.
… seems to confuse the runtime unwinder on linux: https://llvm.org/bugs/show_bug.cgi?id=28757.
…gument in a platform specific non-abi register. This is used to implement the passing of rgctx/imt arguments in mono.
…h was moved into MCObjectStreamer so it can be used whhen emitting assembly as well.
… used to map a mono method index to its associated EH and unwind info.
…, they can be used to disable the building of lib/ExecutionEngine and only build a subset of tools.
…d to the NATIVE build of llvm using -DCROSS_TOOLCHAIN_FLAGS_NATIVE=-DCMAKE_TOOLCHAIN_FILE=$PWD/../cmake/modules/NATIVE.cmake when cross compiling, so the native build uses the host compilers, not the cross compilers.
Mono's LLVM backend was always emitting code like this:
> 000d7234 <double_ToString>:
> d7234: e92d4800 push {fp, lr}
> d7238: ed2d8b02 vpush {d8}
> d723c: ed908b00 vldr d8, [r0]
> d7240: eb12e4e2 bl 5905d0 <plt_System_Globalization_NumberFormatInfo_get_CurrentInfo>
> d7244: e1a03000 mov r3, r0
> d7248: ec510b18 vmov r0, r1, d8
> d724c: e3a02000 mov r2, #0
> d7250: eb12e91a bl 5916c0 <plt_System_Number_FormatDouble_double_string_System_Globalization_NumberFormatInfo>
> d7254: ecbd8b02 vpop {d8}
> d7258: e8bd8800 pop {fp, pc}
despite the correct setting passed to `llc`. Note that passing the floating
point value (`d8`) in the integer registers `r0` and `r1` is wrong.
With this change we get the following:
> 000d9934 <double_ToString>:
> d9934: e92d4800 push {fp, lr}
> d9938: ed2d8b02 vpush {d8}
> d993c: ed908b00 vldr d8, [r0]
> d9940: eb137c2e bl 5b8a00 <plt_System_Globalization_NumberFormatInfo_get_CurrentInfo>
> d9944: eeb00b48 vmov.f64 d0, d8
> d9948: e1a01000 mov r1, r0
> d994c: e3a0000 mov r0, #0
> d9950: eb138066 bl 5b9af0 <plt_System_Number_FormatDouble_double_string_System_Globalization_NumberFormatInfo>
> d9954: ecbd8b02 vpop {d8}
> d9958: e8bd4800 pop {fp, lr}
> d995c: e1a0f00e mov pc, lr
Which matches with what the Mono JIT emits:
> 0: e92d4100 push {r8, lr}
> 4: e24dd028 sub sp, sp, dotnet#40 ; 0x28
> 8: e58d0018 str r0, [sp, dotnet#24]
> c: e59d0018 ldr r0, [sp, dotnet#24]
> 10: ed900b0 vldr d0, [r0]
> 14: ed8d0b08 vstr d0, [sp, dotnet#32]
> 18: eb00000e bl 0x58
> 1c: e1a01000 mov r1, r0
> 20: ed9d0b08 vldr d0, [sp, dotnet#32]
> 24: e3a0000 mov r0, #0
> 28: eb000007 bl 0x4c
> 2c: e28dd028 add sp, sp, dotnet#40 ; 0x28
> 30: e8bd8100 pop {r8, pc}
Both are passing the floating point argument correctly via `d0`.
Fixes mono/mono#11095
* Adjust mono's LLVM calling convention to use win64 calling convention. * Emit both Windows native unwind info + Dwarf unwind info for mono methods. * Don't emit native personality handlers for mono methods. * Handle Mono and Win64 calling convention similarities when needed.
32-bit llc.exe build using i686-w64-mingw32-gcc/i686-w64-mingw32-g++ at least on version 5.3.1 and 5.4.0 triggers an optimization bug crashing the process. This was observed by Android team when running cross compiler targeting armv7-linux-gnueabi using LLVM 6.0. The MatchPhiSet call from findCommon triggered an optimization resulting in incorrect stack pointer adjustment on return. That in turn caused an AV when reading the incorrect pointer from stack representing NewPhiNodes stack variable. The fix will reduce optimization around this function not triggering the optimization rules hitting the bug.
…-windows-x64 Fix correct Dwarf CFI for Windows x64.
[arm] fix CFA when frame pointer is used
There's no guarantee that `ID_AA64ISAR0_EL1` can be read from user-mode, so add to the existing `/proc/cpuinfo` parser instead. See also: - https://www.kernel.org/doc/html/latest/arm64/elf_hwcaps.html - https://developer.arm.com/documentation/100403/0200/register-descriptions/aarch64-system-registers/id-aa64isar0-el1--aarch64-instruction-set-attribute-register-0--el1 - https://elixir.bootlin.com/linux/v5.11.7/source/arch/arm64/kernel/cpuinfo.c#L58 - https://elixir.bootlin.com/linux/v5.11.7/source/arch/arm64/kernel/cpuinfo.c#L66
Adds change from https://reviews.llvm.org/D86126
…indows arm with VS 2019:
```
D:\a\1\s\llvm\include\llvm/ADT/SmallVector.h(524): error C2719: 'Elt': formal parameter with requested alignment of 16 won't be aligned
D:\a\1\s\llvm\include\llvm/ADT/SmallVector.h(554): note: see reference to class template instantiation 'llvm::SmallVectorTemplateBase<T,true>' being compiled
with
[
T=`anonymous-namespace'::Struct16B
]
```
…kages." This reverts commit 24d243c. It's not actually required.
To be consistent with other repos
(cherry picked from commit f287237)
Enable codeql with TSA in separate pipeline
…125.1 (dotnet#323) [dotnet/main] Update dependencies from dotnet/arcade
…129.2 (dotnet#326) [dotnet/main] Update dependencies from dotnet/arcade
…209.3 (dotnet#329) [dotnet/main] Update dependencies from dotnet/arcade
CMake is accidentally picking up zlib from the CI environment, see actions/runner-images#6627 (comment), the build log now has this line: ``` -- Found ZLIB: C:/Strawberry/c/lib/libz.a (found version "1.2.11") ``` Disable zlib on Windows since we don't want the dependency there, this is also what Rust did a while back: rust-lang/rust#85762
We actually built on the wrong image since the `demands` was wrong and it just fell back to a default AzDO image.
…216.1 (dotnet#337) [dotnet/main] Update dependencies from dotnet/arcade
…223.1 (dotnet#339) [dotnet/main] Update dependencies from dotnet/arcade
[dotnet/main] Update dependencies from dotnet/arcade
…108.1 (dotnet#344) [dotnet/main] Update dependencies from dotnet/arcade
…113.7 (dotnet#348) [dotnet/main] Update dependencies from dotnet/arcade
…117.5 (dotnet#350) [dotnet/main] Update dependencies from dotnet/arcade
…127.1 (dotnet#354) [dotnet/main] Update dependencies from dotnet/arcade
…203.1 (dotnet#358) [dotnet/main] Update dependencies from dotnet/arcade
* Apply llvm.patch Taken from https://github.com/dotnet/runtime/blob/7ab969c84ef05ba948c0075392716ce335b47744/src/coreclr/tools/aot/ObjWriter/llvm.patch. * Add objwriter library * Taken from https://github.com/dotnet/runtime/tree/7ab969c84ef05ba948c0075392716ce335b47744/src/coreclr/tools/aot/ObjWriter. * Updated README.md * Updated CMakeLists.txt to remove reference to CORECLR_INCLUDE_DIR. * Added cordebuginfo.h, cvconst.h, cfi.h from coreclr/inc at the above commit. * Build the ObjWriter package * Add ObjWriter API to set DWARF version (dotnet#161) Contributes to https://github.com/dotnet/runtimelab/issues/1738. * Add `.note.GNU-stack` section to produced executables (dotnet#162) Do this unconditionally because there's no scenario where we would need executable stack for managed code. * Remove Darwin workaround (dotnet#163) This caught my attention as I was looking at the ObjWriter. LLVM no longer emits a `LC_VERSION_MIN_MACOSX` load command unless we explicitly set a version. I don't see a difference in `llvm-objdump -macho -x foo.o` with/without these lines (I didn't bother myself to boot into macOS to run `otool`). * Fix llvm-dwarfdump warnings (dotnet#164) Fixes https://github.com/dotnet/runtimelab/issues/1535. No warnings left with llvm-dwarfdump from LLVM 12. * Revert "Fix llvm-dwarfdump warnings (dotnet#164)" (dotnet#218) This reverts commit afc9070. * Add new NuGet package, `Microsoft.NETCore.Runtime.JIT.Tools`, includes `FileCheck` and `llvm-mca` (dotnet#256) https://github.com/dotnet/runtime is wanting to start writing assembly (x64/ARM64) verification tests. Instead of building our own tool to support writing those kinds of tests, we want to leverage LLVM's `FileCheck`. We also want to include `llvm-mca` at the request of @EgorBo This PR creates a new NuGet package for `dotnet/runtime` to consume which we named `Microsoft.NETCore.Runtime.JIT.Tools`. So far, this package only includes LLVM's `FileCheck` and `llvm-mca` tools. * [ObjWriter] Enable DWARF debug information emitting for Mach-O (dotnet#269) * Account for GOT VariantKind on osx-arm64 (dotnet#185) * Add API for emitting compact unwind encoding, enforce DWARF encoding if not explicitly overridden * Add comment * Update ObjWriter to LLVM 14 API * Add support for generating uninitialized sections (dotnet#306) We support `.bss` but not custom sections that are bss-like. This adds such support. * Do not indiscriminately create text section (dotnet#312) If we ended up with nothing in the text section, this line would error LLVM out in: https://github.com/dotnet/llvm-project/blob/3db8d68195c17386557f1a258312bbae4051dc05/llvm/lib/MC/ELFObjectWriter.cpp#L1458-L1459 Because we generate a reference to the empty text section in the `aranges` section. I double checked and debugging on Linux still works fine without this. `SetCodeSectionAttribute` is an objwriter API and we have access to it from the managed side. We should be calling it from there if it's needed for something that I didn't realize (we do call it from the managed side for the `.managed` section, but that one actually has debug information generated, unlike `.text`). * Fix off-by-one error in DWARF reg-reg location (dotnet#317) The DWARF specification states that the form of an exprloc consists of an unsigned LEB128 length value, followed by the encoded location bytes of the specified length. For some reason we were adding one to the length value being emitted. This looks incorrect to me. The above calculation for REG-REG (a variable stored in two registers) correctly calculates the length of each register type tag, plus the size of the interpolating PIECE tags, plus the size of notation for each register. The extra byte looks wrong. I've tested this locally and it appears to resolve dotnet/runtime#77407. Unfortunately, it also causes llvm-dwarfdump --verify to constantly complain about missing base addresses. I can't confirm at the moment, but my suspicion is that this is revealing an existing bug. Even if this is somehow causing a new bug, I think the resulting symbols with this change are better than the alternative (no working symbols at all). * Setting context object file info * Add verbosity to linux x64 pipeline In order to understand what is happening with std path error. * Revert "Add verbosity to linux x64 pipeline" This reverts commit 5c4636e. * Upgrading linux build image * [Temporary] Adding verbosity to get more pipeline error info * Update image name for linux x64 * Fix Linux x64 build * Revert "[Temporary] Adding verbosity to get more pipeline error info" This reverts commit 9d76b36. * Updating Build_Linux_musl timeout * Update linux-musl Docker images * Fix linux-musl-x64 build * Setting clang/++ version 15 for linux musl * Copying clang/clan++ vars to unix-like OS * Fix cut & paste error * Fix objcopy and strip path in cross-compilation * Update azure-pipelines.yml $(ClangVersion) $(ClangPlusVersion) weren't defined for OSX and should be defined for every Linux * Bump timeout for Linux musl build * Clean up .gitignore * Consolidate Clang[Plus]Version into ClangVersionArg * Move CLANG_TARGET from environment into build parameter Always quote _BuildConfig on command line so empty value is not accidentally using next parameter as the value * Update URL in cordebuginfo.h to point to dotnet/runtime * Bump Windows build timeout to 210 * Fix a typo in compiler name * Revert $(_BuildConfig) -> "$(_BuildConfig)" change * Change ClangTarget to ClangTargetArg since apparently it gets propagated as environment variable into wrong steps * Fix inadvertent change * Bump timeout everywhere --------- Co-authored-by: Michal Strehovský <MichalStrehovsky@users.noreply.github.com> Co-authored-by: Andy Gocke <andy@commentout.net> Co-authored-by: Will Smith <lol.tihan@gmail.com> Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com> Co-authored-by: Brian Bohe <brianbohe@gmail.com> Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
….3 (dotnet#361) [dotnet/main] Update dependencies from dotnet/arcade
llvm-dwarfdump produces warnings whenever a debugging entry which is specified to have children has no children. The DWARF spec states that any entry specified to contain children should have at least one child, not including the null entry ending the list of children. It also states that a null entry is allowed, in the place of a child entry. This change adds a null entry in the case that there are no children for the entry.
…otnet#366) This reverts commit 916d70c.
…218.1 (dotnet#368) [dotnet/main] Update dependencies from dotnet/arcade
My previous change in dotnet#363 did not correctly account for all the possible items that could create a child entry. This caused an extra null entry to be created, which was treated as the end of the section. This change is more thorough and features NoChildren abbrev sections, which should hopefully be a little safer, as it will avoid having to produce extra null entries. I've done some extra validation on this change to make sure that roughly the same amount of DWARF info is produced in a test app before and after this change, so it's unlikely that we're truncating most of the info again.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.