Age | Commit message (Collapse) | Author | Files | Lines |
|
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.
|
|
This fix is to update usages of SetupGcCoverage() under
FEATURE_PREJIT aligned to the signature change in #25261.
|
|
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
|
|
Check for `lvLRACandidate` instead of `!lvDoNotEnregister` when checking whether `this` may be enregistered and has an Interval.
|
|
|
|
|
|
|
|
runtest.sh
|
|
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.
|
|
|
|
Fix patch fixes SIGBUG that occurs due to unaligned read/write
|
|
* 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
|
|
|
|
- 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.
|
|
- Even if DACCESS_COMPILE or CROSSGEN_COMPILE is defined,
coreclr can be built without IBCLOGGER_ENABLED definition.
|
|
|
|
|
|
This is needed to save a minicoredump of .NET applications to allows
reconstruct managed stack by lldb and SOS plugin.
|
|
Change-Id: Ia0e1c6aa651c4fd88dc58b901729896a7a27681d
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
- 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
|
|
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.
|
|
* fix principal policy for new threads
Fixes #31717
Co-authored-by: Marco Rossignoli <marco.rossignoli@gmail.com>
|
|
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.
|
|
Remove BMI2 from ASCII and UTF-16 processing hot paths, as not all processors have optimized implementations of pext/pdep
|
|
(#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
|
|
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.
|
|
|
|
* Port PR #258 to 3.1
* Fix test proj file
|
|
Port of dotnet/runtime#1389.
|
|
* 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
|
|
|
|
* 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>
|
|
(#27996)
|
|
eng/Versions.props doesn't seem to be the source of truth for branding
|
|
Basically reverting https://github.com/dotnet/coreclr/pull/26806
|
|
* [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
|
|
|
|
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.
|
|
|
|
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
|
|
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
|
|
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
|
|
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.
|
|
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
|