summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-03-25[Tizen] skip dotnet specific arguments in corerunKonstantin Baladurin1-0/+13
Now we use corerun to run corefx tests instead of dotnet, because last one isn't available for Tizen/armel. So we need to skip dotnet specific arguments, we patch corerun for it because Microsoft.DotNet.RemoteExecutor tries to execute binary that it gets from /proc/self/maps, so we need a binary that will behave like dotnet.
2020-03-25Build error fix on FEATURE_PREJIT=trueSwift Kim2-2/+2
This fix is to update usages of SetupGcCoverage() under FEATURE_PREJIT aligned to the signature change in #25261.
2020-03-25[Linux/x86] Use ebp from current context during unwinding (#26789)Konstantin Baladurin4-15/+21
pCurrentContextPointers in REGDISPLAY can contain NULLs so we need to use ebp value from pCurrentContext. This patch contains following changes: - GetRegdisplayFP returns ebp from pCurrentContext - GetRegdisplayFP is used instead of *GetEbpLocation() - Set##reg##Location also updates register value in pCurrentContext
2020-03-25[JIT/x86] Fix LinearScan::allocateRegisters (#26649)Konstantin Baladurin1-1/+1
Check for `lvLRACandidate` instead of `!lvDoNotEnregister` when checking whether `this` may be enregistered and has an Interval.
2020-03-25Linux/x86: fix build (#26594)Konstantin Baladurin2-0/+3
2020-03-25[Tizen] Pack test libs to coreclr-testGleb Balykov1-0/+1
2020-03-25[Tizen] Add unsupported testsGleb Balykov1-1/+14
2020-03-25[Tizen] Replace new runtest.sh, which calls dotnet internally, with old ↵Gleb Balykov1-256/+1071
runtest.sh
2020-03-25[Tizen] Partially revert a6292a6.Mikhail Kurinnoi1-0/+39
NetcoreDBG depends from PAL functions. Instead of SOS plugin, that use PAL static libs, debugger should be able to operate with any runtime version and can't be statically linked to PAL.
2020-03-25add access(2) call before dlopening filesYaroslav Yamshchikov1-0/+9
2020-03-25corbbtprof: set byte alignment for CORBBTPROF structures (#25816)Konstantin Baladurin1-0/+5
Fix patch fixes SIGBUG that occurs due to unaligned read/write
2020-03-25Fail to explicitly tail call on x86 unix. (#25032)Jarret Shook3-2/+55
* Fail to explicitly tail call on x86 unix. * Correctly return 100 * Correct return value * Add noway assert in morphTailCall to avoid morphing slow tail calls on unix. * Address feedback
2020-03-25[Tizen] Disable jithost arena cacheGleb Balykov1-1/+1
2020-03-25[Tizen] Disable IBC Logger as a defaultDongHeon Jung2-1/+5
- Profile information is collected by ibc logger. Hower it is not used and saved into profile file. - The patch disables IBC logger which is enabled by default. - It disables IBC logger only with ibclogger.h file. IBCLOGGER_ENABLED definition is only used in ibclogger files.
2020-03-25Fix a build error when IBCLOGGER_ENABLED is not defined (#25691)Dong-Heon Jung1-13/+31
- Even if DACCESS_COMPILE or CROSSGEN_COMPILE is defined, coreclr can be built without IBCLOGGER_ENABLED definition.
2020-03-25[Tizen] Enable PGO for Linux/armKonstantin Baladurin4-4/+27
2020-03-25[Tizen] seperate PIC and PIE to fix x86_64 build errorWoongsuk Cho1-3/+5
2020-03-25[Tizen] Add a library to retrieve memory regions for a coredumpMateusz Moscicki9-15/+340
This is needed to save a minicoredump of .NET applications to allows reconstruct managed stack by lldb and SOS plugin.
2020-03-25[Tizen] update cscope files to be ignoredHyungju Lee1-0/+4
Change-Id: Ia0e1c6aa651c4fd88dc58b901729896a7a27681d
2020-03-25Fix OOPStackUnwinderX86::Unwind crash when Eip is invalidIgor Kulaychuk1-1/+1
2020-03-25Fix EECodeManager::GetAmbientSP on x86/LinuxIgor Kulaychuk1-1/+2
2020-03-25[Tizen] Add -pie to linker optionHyungju Lee1-0/+1
There have been no -pie linker option. This patch adds -pie linker option into crossgen(for tizen) This originates from 0024-Add-pie-to-linker-option.patch
2020-03-25[Tizen] Add support for GBSjunghyuk.park5-6/+354
2020-03-25[Tizen] Add prebuilt libicu-57.1 librariesjunghyuk.park24-0/+16
2020-03-25[Tizen] Add BuildTools v3.1.3Gleb Balykov4651-0/+1368388
2020-02-18[3.1] Fail FuncEval if slot backpatching lock is held by any thread (#28006)Koundinya Veluri4-3/+89
- In many cases cooperative GC mode is entered after acquiring the slot backpatching lock and the thread may block for debugger suspension while holding the lock. A FuncEval may time out on entering the lock if for example it calls a virtual or interface method for the first time. Failing the FuncEval when the lock is held enables the debugger to fall back to other options for expression evaluation. - Also added polls for debugger suspension before acquiring the slot backpatching lock on background threads that often operate in preemptive GC mode. A common case is when the debugger breaks while the tiering delay timer is active, the timer ticks shortly afterwards (after debugger suspension completes) and if a thread pool thread is already available, the background thread would block while holding the lock. The poll checks for debugger suspension and pulses the GC mode to block before acquiring the lock. Risks: - The fix is only a heuristic and lessens the problem when it is detected that the lock is held by some thread. Since the lock is acquired in preemptive GC mode, it is still possible that after the check at the start of a FuncEval, another thread acquires the lock and the FuncEval may time out. The polling makes it less likely for the lock to be taken by background tiering work, for example if a FuncEval starts while rejitting a method. - The expression evaluation experience may be worse when it is detected that the lock is held, and may still happen from unfortunate timing - Low risk for the change itself Port of https://github.com/dotnet/runtime/pull/2380 Fix for https://github.com/dotnet/runtime/issues/1537
2020-02-18Port dotnet/runtime#31946 to release/3.1 branch (#28014)Levi Broderick1-1/+5
When string.Replace is given a target string with zero collation weight, it would enter an infinite loop. It is now changed so that the call to Replace terminates when such a condition is encountered.
2020-02-18Fix AppDomain.SetPrincipalPolicy bug for new threads (#32104) (#28019)Eirik Tsarpalis1-3/+4
* fix principal policy for new threads Fixes #31717 Co-authored-by: Marco Rossignoli <marco.rossignoli@gmail.com>
2020-02-18Fix build on systems with glibc >= 2.30 (#28012)Omair Majid1-0/+4
On newer systems with glibc 2.30, the compiler emits a warning: In file included from coreclr/src/pal/src/misc/sysinfo.cpp:32: /usr/include/sys/sysctl.h:21:2: error: "The <sys/sysctl.h> header is deprecated and will be removed." [-Werror,-W#warnings] #warning "The <sys/sysctl.h> header is deprecated and will be removed." ^ The glibc 2.30 release notes cover this at https://sourceware.org/ml/libc-alpha/2019-08/msg00029.html: * The Linux-specific <sys/sysctl.h> header and the sysctl function have been deprecated and will be removed from a future version of glibc. Application should directly access /proc instead. For obtaining random bits, the getentropy function can be used. To keep coreclr release/3.1 building, disable treating the #warning as an error. Clang and GCC have separate flags to turn this error off.
2020-02-18Port dotnet/runtime#31904 to release/3.1 (#28013)Levi Broderick3-156/+92
Remove BMI2 from ASCII and UTF-16 processing hot paths, as not all processors have optimized implementations of pext/pdep
2020-02-14Update dependencies from https://github.com/dotnet/arcade build 20200213.5 ↵dotnet-maestro[bot]12-56/+200
(#28018) - Microsoft.DotNet.Arcade.Sdk - 1.0.0-beta.20113.5 - Microsoft.DotNet.Build.Tasks.Feed - 2.2.0-beta.20113.5 - Microsoft.DotNet.Build.Tasks.Packaging - 1.0.0-beta.20113.5 - Microsoft.DotNet.Helix.Sdk - 2.0.0-beta.20113.5
2020-02-13Port of dotnet/runtime#1059 to 3.1 branch (#27986)Carol Eidt3-2/+102
This is the fix for #27924. This is a GC hole bug that was found externally, #27590. The cause is that the JIT was using the target type of the subtract when it needed to make a copy of the source, but it needs to use the source type. ## Customer Impact Corruption of state that is non-deterministic and hard to track down. ## Regression? Not a recent regression, but exposed by Unsafe.ByteOffset. ## Testing The fix has been verified in the runtime repo. ## Risk Low: The fix is straightfoward and only impacts 3 lines of code.
2020-02-13Port fix for #1241 to 3.1 (#27983)Carol Eidt3-12/+123
2020-02-13Port PR #258 to 3.1 (#27984)Carol Eidt3-6/+81
* Port PR #258 to 3.1 * Fix test proj file
2020-02-13Fix GC heap corruption on ARM. (#27985)Anton Lapounov1-1/+1
Port of dotnet/runtime#1389.
2020-02-13Port the 5.0 fix for issue #1104 (#28003)Brian Sullivan3-1/+96
* Port the 5.0 fix for issue #1104 3.1 - Pull Request Runtime\#1734 - This change corrects a cut-and paste typo with a previous commit. - Includes test case Runtime_1104.cs * Updated the csproj to use 3.1 syntax
2020-02-13update branding for 3.1.3 (#28016)Anirudh Agnihotry2-2/+2
2020-01-16[automated] Merge branch 'release/3.0' => 'release/3.1' (#28002)dotnet-maestro-bot5-5/+24
* Fix Segfault in PerfInfo Image Logging (#26910) * update branding for 3.0.2 (#27896) * update branding * remove stable properties from coreclr as it never stablises * [release/3.0] Fix use of ilasm during test builds when using a 3.0 SDK (#27820) * Add fix for restore of ilasm The restore logic in buildtools tried to use a netcoreapp2.1 TFM for Linux-musl. This ended up restoring Linux-x64 binaries which then broke the test build. This change works around this by saving a copy of the depproj that BuildTools used into the tree and restore it as a 3.0 app manually in init-tools on our side of the build. * Change to a 3.0 SDK for servicing * Bump test versions of ilasm and runtime package to match the RC * Move off of the old arm32 queue (#27905) * Add alpine3.10 testing to 3.0 (#27214) * Fix GetSequencePoints when profiler provides mapping via SetILInstrumentedCodeMap (#27843) Port #25802 to 3.0.2 * [release/3.0] Update dependencies from dotnet/core-setup (#27910) * Update dependencies from https://github.com/dotnet/core-setup build 20191016.12 - Microsoft.NETCore.App - 3.0.1-servicing-19516-12 * Update dependencies from https://github.com/dotnet/core-setup build 20191121.02 - Microsoft.NETCore.App - 3.0.2-servicing-19571-02 * update brandint to 3.0.3 (#27993) * Update branding to 3.0.3 (#27997) eng/Versions.props doesn't seem to the the source of truth for branding * Fix infrastructure issues in release 3.0 (#28000) * Restore Helix SDK using Tools.props to work around MSBuild race condition * Disable formatting jobs * Disable ARM windows jobs * Fix tracing in RHEL6 build * [release/3.0] Update dependencies from dotnet/arcade (#26889) * Update dependencies from https://github.com/dotnet/arcade build 20190924.3 - Microsoft.DotNet.Arcade.Sdk - 1.0.0-beta.19474.3 - Microsoft.DotNet.Build.Tasks.Feed - 2.2.0-beta.19474.3 - Microsoft.DotNet.Build.Tasks.Packaging - 1.0.0-beta.19474.3 - Microsoft.DotNet.Helix.Sdk - 2.0.0-beta.19474.3 * Update NuGet.config * Update runtime versions * Update dependencies from https://github.com/dotnet/arcade build 20191119.2 - Microsoft.DotNet.Arcade.Sdk - 1.0.0-beta.19569.2 - Microsoft.DotNet.Build.Tasks.Feed - 2.2.0-beta.19569.2 - Microsoft.DotNet.Build.Tasks.Packaging - 1.0.0-beta.19569.2 - Microsoft.DotNet.Helix.Sdk - 2.0.0-beta.19569.2 * Update dependencies from https://github.com/dotnet/arcade build 20191122.3 - Microsoft.DotNet.Arcade.Sdk - 1.0.0-beta.19572.3 - Microsoft.DotNet.Build.Tasks.Feed - 2.2.0-beta.19572.3 - Microsoft.DotNet.Build.Tasks.Packaging - 1.0.0-beta.19572.3 - Microsoft.DotNet.Helix.Sdk - 2.0.0-beta.19572.3 * Update dependencies from https://github.com/dotnet/arcade build 20191127.5 - Microsoft.DotNet.Arcade.Sdk - 1.0.0-beta.19577.5 - Microsoft.DotNet.Build.Tasks.Feed - 2.2.0-beta.19577.5 - Microsoft.DotNet.Build.Tasks.Packaging - 1.0.0-beta.19577.5 - Microsoft.DotNet.Helix.Sdk - 2.0.0-beta.19577.5 * Add coreclr static feed to NuGet.config Co-authored-by: Matt Mitchell <mmitche@microsoft.com> Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com> Co-authored-by: Brian Robbins <brianrob@microsoft.com> Co-authored-by: Anirudh Agnihotry <anirudhagnihotry098@gmail.com> Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com> Co-authored-by: Jarret Shook <jashoo@microsoft.com> Co-authored-by: David Mason <davmason@microsoft.com> Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Matt Mitchell <mmitche@microsoft.com>
2020-01-15[release/3.1] Port fix to revert EncoderNLS and DecoderNLS Convert changes ↵Levi Broderick3-10/+38
(#27996)
2020-01-15Update branding to 3.1.2 (#27998)Matt Mitchell1-1/+1
eng/Versions.props doesn't seem to be the source of truth for branding
2020-01-14Revert CPU clipping in the presence of CPU quota to 3.0, 2.x behavior.Vladimir Sadov3-0/+17
Basically reverting https://github.com/dotnet/coreclr/pull/26806
2020-01-14[release/3.1] Port fix for JIT silent bad code (#27972)Andy Ayers3-5/+101
* [release/3.1] Port fix for JIT silent bad code Release/3.1 port of https://github.com/dotnet/runtime/pull/797. Fixes https://github.com/dotnet/runtime/issues/764 The jit might incorrectly order a read from a struct field with an operation that modifies the field, so that the read returns the wrong value. Silent bad code; program behaves incorrectly. Yes, introduced in the 3.0 cycle. Verified the user's test case now passes; no diffs seen in any existing framework or test code. **Low**: the jit is now spilling the eval stack entries to temps in cases where it did not before; this should be conservatively safe. cc: @brucefo ____ If we're appending an assignment whose LHS is is a location within a local struct, we need to spill all references to that struct from the eval stack. Update the existing logic for this to handle the case where the LHS is a field of a local struct, and the field is updated by unusual means (here, `initobj`). Fixes dotnet/runtime#764. * Fix test
2020-01-14Fix CancellationTokenRegistration.Unregister race condition (#27949)Stephen Toub1-1/+9
2020-01-14Release/3.1 port of dotnet/runtime#239 (#27973)Andy Ayers3-1/+73
Fix for #27923 The jit might fail to locate a class handle for a ref class, leading to an unexpected crash while jitting. ## Customer Impact Unexpected and hard to diagnose crash/exception ## Regression? Yes, introduced during the development 3.0 cycle. 2.x behaves correctly. ## Testing Verified the user's test case now passes; no diffs seen in any existing framework or test code. ## Risk **Low**: the jit will now fall back to using the handle for System.Object if no better option can be found. cc @BruceForstall ____ In some cases we may end up in lvaSetClass without a valid ref class handle from either the IR or the stack. Use the handle for object as a conservative fallback.
2020-01-14Fix EventSource to stop ignoring EventCommand.SendManifest (#27979)Sung Yoon Whang1-2/+0
2020-01-14Stop throwing exception in TimeZoneInfo POSIX parsing (#27969)Eric Erhardt2-33/+26
IsDaylightSavingTime_CasablancaMultiYearDaylightSavings fails on rhel.8 When parsing the tzdata POSIX string that contains an 'n' Julian date, we are currently throwing an exception, and then falling back to a TimeZoneInfo without DST enabled. However, this is a mistake because there are other DST transitions that were read from the tzdata file that are valid and usable. We shouldn't be throwing that information away. So instead, we now skip the POSIX string if we detect an unsupported 'n' Julian date, and just use the last transition as the AdjustmentRule for all the DateTimes in the future. This way we can still make DST determinations correctly for some DateTimes. Fix https://github.com/dotnet/corefx/issues/42192
2020-01-14This is a point fix for not allowing fast tail calls on windows arm64 for ↵Jarret Shook1-0/+13
vararg methods (#27963) * This is a point fix for not allowing fast tail calls on windows arm64 This only affects windows arm and arm64. * Fix build break
2020-01-14Port to 3.1 - Fix out of range access in GetRecycleMemoryInfo (#27959)Jan Vorlicek1-1/+3
Ports change #26873 to release 3.1 branch. On OpenVZ virtualized linux, GetCurrentProcessorNumber which uses sched_getcpu() can return a value greater than the number of processors reported by sched_getaffinity with CPU_COUNT or sysconf(_SC_NPROCESSORS_ONLN). For example, taskset -c 2,3 ./MyApp will make CPU_COUNT be 2 but sched_getcpu() can return 2 or 3, and OpenVZ kernel can make sysconf(_SC_NPROCESSORS_ONLN) return a limited cpu count but sched_getcpu() still report the real processor number. Example of affinity vs current CPU id on OpenVZ: nproc: 8 nprocOnline: 1 affinity: 1, 0, 0, 0, 0, 0, 0, 0, cpuid: 2 affinity: 1, 0, 0, 0, 0, 0, 0, 0, cpuid: 2 affinity: 1, 0, 0, 0, 0, 0, 0, 0, cpuid: 2 affinity: 1, 0, 0, 0, 0, 0, 0, 0, cpuid: 2 affinity: 1, 0, 0, 0, 0, 0, 0, 0, cpuid: 2 affinity: 1, 0, 0, 0, 0, 0, 0, 0, cpuid: 5 affinity: 1, 0, 0, 0, 0, 0, 0, 0, cpuid: 5
2020-01-14Port to 3.1 - Fix VirtualMemoryLogging::logRecords overflow (#27958)Jan Vorlicek1-4/+4
when VirtualMemoryLogging::recordNumber increments from LONG_MAX, it became negative number, and the result of i % MaxRecords became a number from -127 to 0. When that happens we will ovewrite CRITICAL_SECTION virtual_critsec which are stored in bss right before logRecords with garbage data. Then most likely the process will have a GC hang with one or more GC threads stuck trying to enter or leave critical section. The fix is to ensure ULONG value are passed to modulo operation.
2020-01-14Port to 3.1 - Fix getting affinity set on MUSL on Jetson TX2 (#27957)Jan Vorlicek3-5/+4
Ports https://github.com/dotnet/runtime/pull/206 to release/3.1. The code in PAL_GetCurrentThreadAffinitySet relied on the fact that the number of processors reported as configured in the system is always larger than the maximum CPU index. However, it turns out that it is not true on some devices / distros. The Jetson TX2 reports CPUs 0, 3, 4 and 5 in the affinity mask and the 1 and 2 are never reported. GLIBC reports 6 as the number of configured CPUs, however MUSL reports just 4. The PAL_GetCurrentThreadAffinitySet was using the number of CPUs reported as configured as the upper bound for scanning affinity set, so on Jetson TX2, the affinity mask returned had just two bits set while there were 4 CPUs. That triggered an assert in the GCToOSInterface::Initialize. This change fixes that by reading the maximum CPU index from the /proc/cpuinfo. It falls back to using the number of processors configured when the /proc/cpuinfo is not available (on macOS, FreeBSD, ...) Fixes https://github.com/dotnet/runtime/issues/170