Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

viewing diff: dotnet/main -> release/14.x #1

Open
wants to merge 81 commits into
base: release/14.x
Choose a base branch
from

Conversation

markples
Copy link
Owner

No description provided.

akoeplinger and others added 30 commits May 13, 2022 13:33
To be consistent with other repos
…net#190)

This should make it possible to use an Apple M1 mac to work on WebAssembly.

The trick is that for cross-compiling `libclang` we need a host `clang-tblgen` not just a host `llvm-tblgen`.

(cherry picked from commit d1be520)
(cherry picked from commit f287237)
(cherry picked from commit 32567e0)
We're not supposed to set it manually, CMake will set it based on the CMAKE_SYSTEM_NAME.
See llvm#52819 where the llvm docs were updated to recommend setting CMAKE_SYSTEM_NAME instead of CMAKE_CROSSCOMPILING when cross-compiling
This works around an issue where we'd require Python 3.6 even though building llvm itself doesn't require it.
[dotnet/main] Update dependencies from dotnet/arcade
….1 (dotnet#209)

[dotnet/main] Update dependencies from dotnet/arcade
…601.2 (dotnet#211)

[dotnet/main] Update dependencies from dotnet/arcade
…613.1 (dotnet#213)

[dotnet/main] Update dependencies from dotnet/arcade
…616.2 (dotnet#215)

[dotnet/main] Update dependencies from dotnet/arcade
…627.1 (dotnet#216)

[dotnet/main] Update dependencies from dotnet/arcade
…627.2 (dotnet#219)

[dotnet/main] Update dependencies from dotnet/arcade
…708.3 (dotnet#224)

[dotnet/main] Update dependencies from dotnet/arcade
…717.1 (dotnet#228)

[dotnet/main] Update dependencies from dotnet/arcade
* Add a parameter to force use of devtoolset7 and consume it
* Bump to CentOS container with devtoolset 7 (Ubuntu 18.04 compatible)
* Always build in Release - but on Windows, link Debug MSVC in Debug

* Generate packages with Debug in the name

* Clean more unused files from install dir
…722.1 (dotnet#230)

[dotnet/main] Update dependencies from dotnet/arcade
It is causing Component Governance errors.
The preview image hits a build issue on Windows arm64 and the stable image now contains the MSVC ABI break that caused us to use the preview image before.

Also switch over to the new image names that dnceng wants us to use.
…729.10 (dotnet#233)

[dotnet/main] Update dependencies from dotnet/arcade
…805.6 (dotnet#239)

[dotnet/main] Update dependencies from dotnet/arcade
It was not possible to set the copyright string for binaries. The RC_COPYRIGHT string in the windows resource definition would always be empty. Plumb this value through and set it explicitly in our CMAKE options.

(cherry picked from commit 7346f96)
dotnet-maestro bot and others added 30 commits October 31, 2022 15:09
…024.5 (dotnet#305)

[dotnet/main] Update dependencies from dotnet/arcade
…104.2 (dotnet#308)

[dotnet/main] Update dependencies from dotnet/arcade
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.
…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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.