| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* [squashed] most work complete to enable EventPipe on Windows
* Eventpipe now builds on Windows
* Ensure evevntpipe is intialized on Windows
* Resolve the location of python from build.cmd
* Ensure eventing files are generated when needed
* moving linkage declaration to cmake
* create new event from constructor
* enable FEATURE_EVENT_TRACE and FEATURE_PERF_TRACE everywhere
* [WIP] checkpoint in fixing contarct errors
* add another possible python location
* Fix double delete bug in EventPipeConfiguration destructor
* Fix typo in function name
* Revert changes to .gitgnore
* bump to netstandard1.6 in preperation for new version of TraceEvent
* Revert changes to groovy files
* revert changes to perf-prep scripts
* add common.h and use nothrow
* Fix issue which was causing double delete of configprovider
* Add new test utilizing TraceEvent
* Remove accidentally added local directory reference
* Add comment to explain the addition of misc/tracepointprovider.cpp
* Add back sys.exit(0) and refactor
* Change conditional to be more direct
* Better handle NULL config
* Initialize m_deleteDefered
* Eliminate obsolete field
* Fix spelling error
* Fix nits
* Make smaple progiler timing functions easier to read
* Move projects back to netstandard1.4
* Incomplete improvements to EventPipeTrace test
* Add event integrity checks to test
* Clean up some left over code
* Add EventSource based test
* Remove unused PAL tests on Windows
* Fix Linux build breaks
* Minor changes to CMake files
* Remove //HACK for hack that was previously removed
* Fix formatting and negate a #ifdef
* Add conditional to ensure PERFTRACING is not enabled without EVENT_TRACE
* Take lock on EventPipeProvider and EventPipeConfiguration destruction
* Load winmm.dll at runtime
* Change function name and compile conditions
* Move typedef into #ifndef
* Use the correct config in setup
* Change lifecycle managment of EventPipeConfiguration's configuration provider
* Enable EventPipe tests pri0 and disable broken tests
* Replace python3 only error with python2 compatable one
* Make common.csproj build pri0
* Change TraceEvent version to 2.0.2 to match published verison
* Address cross build failure
* Remove use of undefined variable
* Add crossgen fix to .cmd
* Use more specific types to avoid marshalling errors
* Use Assert-style statements and remove one check
* Fix cross arch build
* Fix flipped branch
* Bring build.cmd changes to build.sh
* Fix cmake writing
* Revert "Bring build.cmd changes to build.sh"
This reverts commit 893c6492548d8bc9859ebba5b1b810aa630fac63.
* remove stdlib.h
* Fix out of order null check
|
|
|
|
RyuJIT/arm32 JIT is now named clrjit.dll (was named protojit.dll).
arm32 LEGACY_BACKEND JIT is now named legacyjit.dll (was named clrjit.dll).
Ubuntu and Tizen testing now use RyuJIT/arm32.
Tests failing for legacy backend are now excluded with `LEGACYJIT_JITSTRESS_FAIL`,
`LEGACYJIT_GCSTRESS_FAIL`, and `LEGACYJIT_FAIL`.
|
|
Currently, an ARM build and CI test run uses the legacy backend
arm32 JIT. This change enables a build of RyuJIT/arm32 as a
cross-targeting protojit.dll (altjit) in the cross tools (placed
next to the x86 hosted crossgen.exe in the build), and uses that
RyuJIT/arm32 cross-compiler to build System.Private.CoreLib.dll.
The CI system when testing RyuJIT/arm32 will use this to test
the crossgen'ed System.Private.CoreLib.dll built by RyuJIT/arm32
for all "arm" architecture jobs.
|
|
* Fix build break when VS2015 is not installed.
If you ONLY install VS2017 (now the common scneario)
and build coreclr, it will fail with COM with a Class_Not_Registered error
This is because a build-tools package is depending on an old COM object
that has gone way in VS2017.
While we sort getting a proper fix, this makes the work-around (which
is registering the DLL by hand) discoverable.
See https://github.com/dotnet/coreclr/issues/11305 for details.
* typo
|
|
abstract MSBuild /maxcpucount switch (#14578)
This commit frees -ExtraParameters and uses MSBuild v15 extension point to control CL compiler parallelism.
If MSBuild 15.0 is available - installed with Visual Studio 2017 - CL parallelism control is achieved by using extension point in Microsoft.Common.props file which allows to include Directory.Build.props - for details see [Microsoft.Common.props] [1] file in MSBuild repo. https://github.com/Microsoft/msbuild/blob/b38e4ceeaaec36c5237ae698041e9b9f18c84876/src/Tasks/Microsoft.Common.props#L36.
MSBuild parallelism is controled via abstracted /maxcpucount command line switch
which now is available as -MSBuildNodeCount pass through run.cmd/run.sh command line
argument with default value equal to /maxcpucount (what defaults to number of logical processors).
This allows to control MSBuild parallelism on all supported platforms.
It is possible to control MSBuild parallelism programatically via MSBuild public
API using MaxNodeCount properties available on the following APIs:
Microsoft.Build.Evaluation.ProjectCollection.MaxNodeCount
Microsoft.Build.Execution.BuildParameters.MaxNodeCount
It's use in current build infrastructure would require creating unnecessary
complexity and was ruled out.
|
|
This argument is intended to be passed through directly to msbuild,
but CMD doesn't handle `=` well, so using `-priority=N` with
`build all` didn't work, for instance.
Add special handling for the `-priority` argument to get around
this problem.
|
|
|
|
Allow building arm64 using VS2017 tools
|
|
Fix Windows arm target cross build: detect prerelease VS2017, stay in repo root
|
|
* First cut of the load protocol
* Implement for non-standalone GC
* Initial working implementation
* First steps towards not using GetProcAddress when not using a standalone GC
* Factor out loading routines into standalone and non-standalone cases
* Remove the FEATURE_STANDALONE_GC_ONLY build
* Code cleanup and comments
* Comments for the version numbers
* Use more appropriate type for config string
* add GC_LOAD_STATUS_BEFORE_START to disambiguate failures before the start of the load and failures at the beginning of the load
* FEATURE_STANDALONE_GC on by default
* Implement YieldProcessor and MemoryBarrier for arm and arm64
* Remove missed FEATURE_STANDALONE_GC feature check
|
|
VS2017 now includes ARM64 compilers. Change the build scripts so
that the normal VC tools path is used for the builds for ARM64.
However, if -toolset_dir is passed, then use the specified tools,
as before.
|
|
|
|
|
|
improvement (#14509)
* Fix native build overparallelism
* Fix native build parallelization problems
* Allow overriding all build workaround parameters
* Fix cleanup ommisions and local environment variable naming
* Address code review feedback
* Fix nul spelling and add standard message prefix
* Simplify settings for CL compiler parallelism
* Address code review feedback - remove whitespace
|
|
Fixes issue #14514
Arm Windows build was recently changed by adding vswhere based VS installation detection
and earlier initialization of environment variables. For details see
https://github.com/dotnet/coreclr/pull/14228/files#diff-02389dfac0a172ab80211625efc34318R22
This introduced the following problems: (i) inability to detect and use VS 15 preview releses,
(ii) unexpected changes to working directory caused by VsDevCmd.bat script execution. These
errors prevented an arm Windows build on my machine with different errors. In particular due
to presence of arm tools only in preview version of VS the arm build consistently failed with
CMake error "compiler unknown". Fixing of this problem unmasked second bug introduced by
uncontrolled changes to build script working directory resulting in error: "Command line too
long". Both problems are fixed in this PR.
In addition in CrossArchBuild leg a new CMake custom argument is introduced which allows for
selection of latest Windows 10 SDK available on machine directly by CMake. So far this define
was present only in CoreCLR native build leg.
|
|
* Allow not to build SOS.NETCore.dll
* Automatically enable SkipSOS when a mscorlib option is given
|
|
* Update Buildtools and Roslyn
* Fixing importing of the roslyn files on msbuild 14.0
* Correctly looking for the latest VS Installation
|
|
|
|
(#12581)
On Windows, PGO instrumented builds (build.cmd release <arch>
pgoinstrument) introduce a runtime dependency on pgort<ver>.dll for
instrumented binaries. This DLL is distributed alongside the C++
compiler, and is made available via the native tools environment that
ships with Visual Studio.
Previously, we were using cmake to find and "install" this binary
alongside the product when doing an instrumented build, so that the
resulting bin\Product drop is free of any added external dependencies.
However, this approach is fragile, and despite a best effort to make the
implementation work across multiple VS releases, it already broke with
VS 2017.
To fix support for pgoinstrument on VS 2017, and to harden the
implementation for future releases of VS, I'm removing the custom cmake
install logic for the pgort DLL. Instead, we fall back to the officially
supported method: load the correct (native tools) environment before
invoking any command that uses an instrumented binary. This happens in
one place in the build today--loading the JIT to crossgen
System.Private.CoreLib.dll.
Note that there's still an existing CLI/Setup bug that requires copying
the pgort DLL. We're now doing it from within build.cmd, which is not
nearly as fragile for this as cmake is. The workaround is also isolated,
so when the referenced issue is fixed, the workaround (as documented)
can simply be removed.
Fixes #12347.
|
|
The flag is not implemented anywhere and is completely ignored. Remove
it form various help notices too.
Fixes #12035
|
|
The product and test build scripts invoke Visual Studio environment
setting scripts several times during the build process. If doing a full
cross architecture build including test build, it's as many as five times.
These environment changes are cumulative. For the PATH variable, in
particular, they can lead to a failure by exceeding the variable
length limit. This seems to have been exacerbated by VS2017, which
has very long paths, and for which many things are added to the PATH.
Fix this by adding "setlocal" / "endlocal" around various sections
of the scripts, so that the multiple calls to the environment script
are not cumulative.
(There is still some cumulative environment setting, as build.cmd
calls VsDevCmd.bat, then if tests are being built, calls build-test.cmd,
which also calls VsDevCmd.bat, and then possibly in addition calls
vcvarsall.bat.)
In addition, I simplified the code that sets up the msbuild logging
parameters, so it is more readable, regular, and doesn't have so
much repeated text.
|
|
* Add variables to pipeline to enable enforcepgo for Release
* Address review
|
|
* Fix IndexOutOfRangeException in PayloadNames property
If you pass an null payload using Write<T>, and in the EventListener then call PayloadNames, it
will throw an IndexOutOfRangeException. It should just return null. This fixes this.
* To be consistant with the other build.cmd files use - for options
* Update docs to track change in option convention
* Updated Unix script to use - for options.
* Fix build break
* Fix Whitespace (review feedback)
* Another fix
|
|
* Fix bug where whitespace breaks arg proccessing
* Fix whitespace proccessing bug in buil-text.cmd
|
|
(#13258)
* Added PGO execution verification script
Added a script which can help verify whether or not PGO was used
to compile PE files passed to it
* Added target to enforce PGO compilation
* Remove OS checking for enforcepgo
|
|
|
|
|
|
Added info on /verbose option to PrintUsageHelper()
Convert printf(ascii) to wide strings in methodtable.cpp
In build.cmd echo the crossgen /CreatePdb command line
|
|
|
|
This is helpful when performing JIT throughput measurements.
|
|
Avoid restoring optdata during a non-release build to minimize work done
by build.sh/cmd. Fix #12126
|
|
|
|
Integration from dev/local-gc into master
|
|
Fix optdata restore functionality (#11935)
Bring back optdata restore functionality following the move to 2.0
BuildTools and csproj-based CLI. Disable a harmless warning that broke
the Linux build when consuming PGO counts due to -Werr.
Fix #11796 for master
|
|
* Configure the build system to build a CoreCLR capable of loading a standalone GC
* Proto-implementation of dynamic GC loading
* Build the GC with the VM's CMakeLists when doing a non-standalone build of the GC
* [Local GC] Introduce a new feature define, FEATURE_STANDALONE_GC_ONLY, to be used by the CI to explicitly test local GC dynamic loading code paths
* Fix the FEATURE_STANDALONE_GC_ONLY build for unix linkers
* Rebase against master
* Code review feedback: use the existing Unix exports file
|
|
|
|
These changes remove support for the x86 compat JIT from the build, the
runtime, and the various perf/test scripts.
Fixes #10733, #10734.
|
|
Enable binding to CoreLib as NI image
|
|
|
|
In order to avoid confusion, do not build and package compatjit.dll
unless we are building JIT32.
Fixes #10106.
|
|
|
|
* Enable Portable RID support for Windows and OSX.
|
|
|
|
Add a new build switch, `ibcinstrument`, that adds `/Tuning` on the `crossgen`
command line when building System.Private.CoreLib and its peers. Automatically
consume IBC optdata during builds when these conditions are met:
1. `ibcinstrument` is *not* passed to the build,
2. optdata is available
3. ibcmerge is available
Note that `optdata` will not yet be restored with this change; once packages for
master are made available, a new package reference will still need to be added.
This PR attempts to unblock manually testing IBC, as well as surrounding
CI/infrastructure work.
To help produce an IBC-optimized build using manually generated profile data,
run the newly added `tests/scripts/optdata/bootstrap.py` script. It will
configure the build to consume IBC data from a path automatically, and print out
that path where profile data can be copied.
|
|
Fixes #7607
|
|
Updating the build scripts to support VS2017.
|
|
Since we require a compatjit.dll to be built so the JIT NuGet
package can be built, even if JIT32 isn't being built, change
the compatjit.dll build (when JIT32 isn't being built) to just
a normal JIT build.
|
|
The bulk of this PR is a cherry-pick of commit fa02660 that shipped in
release/1.1.0, updating the build system support for PGO to support
consuming PGDs properly during release builds on Windows.
Also included are the following new changes:
* Skip restore of opdata if the requisite project.json is missing
* If the optdata package restore fails, fail the build.
* Add new build option: 'skiprestoreoptdata'
Note: This change doesn't by itself enable PGO in master yet, because
training data (optdata packages) for master don't exist on myget yet.
However, with these changes, the only step remaining to enable PGO
optimizations is to add a project.json referencing the correct optdata
package.
|
|
VS version selection logic.
|
