| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
* Fix ARM/ARM64 hijacking in tail calls
This change fixes an issue that can happen when a function that has tail
calls is hijacked. There are two potential issues:
1. When a function that tail calls another one is hijacked, the LR may be
stored at a different location in the stack frame of the tail call
target.
So just by performing tail call, the hijacked location becomes invalid and
unhijacking would corrupt stack by writing to that location.
2. There is a small window after the caller pops LR from the stack in its
epilog and before the tail called function pushes LR in its prolog when
the hijacked return address would not be not on the stack and so we would
not be able to unhijack.
The fix is to prevent hijacking of functions that contain tail calls.
* Enable the tailcall hijacking test for ARM64
The test JIT/Methodical/tailcall_v4/hijacking should be passing now on
ARM64.
|
|
Otherwise, using the normal GCInfo library, the altjits will
assert creating GC info.
Create new "cross-target" builds of the GCInfo library.
|
|
|
|
The non-X86 GcInfoEncoder library uses two bit-arrays to keep track
of pointer-liveness. The BitArrays are allocated using the arena allocator
which doesn't zero-initialize them. This was causing non-deterministic
redundant allocation of unused slots. This change fixes the problem.
|
|
MEASURE_INFO switch now depends on _DEBUG switch. Ensure NumUntracked,
UntrackedSlotSize, NumUntrackedSize and EncPreservedSlots fields handled correctly in
GcInfoSize::operator+=() and GCInfoSize::Log().
fix #6008
|
|
|
|
|
|
This checkin has two changes:
1) Add a check to ensure that methods with struct-returns are
use the fat header which encodes ReturnKind in 4 bits.
2) Fix a bug in GetReturnKind().
|
|
|
|
!verify heap
!u
!u -gcinfo
|
|
Ref #4379
This change implements GcInfo version 2 for all platforms that use the
GcInfo library (all architectures other than X86).
Changes are:
1) Defines ReturnKind enumeration for all platforms
2) Change the GcInfo encoder library to encode the ReturnKind and ReversePInvokeFrame slot
3) Change the CM's GcInfo decoder to encode the ReturnKind and ReversePInvokeFrame slot for GCINFO_VERSION 2
4) Some corrections to GCINFO_MEASUREments
5) Changes to RYU Jit to provide the correct information to the encoder
6) Changes to the VM to use the ReturnKind information while hijacking a thread
- If ReturnKind is available from GcInfo, new hijack routines are used
- Otherwise, fall back to old method (for compatibility)
7) Rework and simplify the thread hijack routines by scanning HijackFrames directly for gcroots
8) Supporting code to implement the above features.
Returning Structs in multiple registers
Hijacking for StructInRegs is currently only implemented for
Unix SystemV ABI Multi-reg struct returns. However, the hijack-workers that use
ReturnKind are ready to handle other platforms (ex: ARM/ARM64 Windows)
once the corresponding HijackTripThread() assembly routines are defined.
The New feature flag: FEATURE_MULTIREG_RETURN is set for platforms where a struct value
can be returned in multiple registers [ex: Windows/Unix ARM/ARM64, Unix-AMD64]
FEATURE_UNIX_AMD64_STRUCT_PASSING is a specific kind of FEATURE_MULTIREG_RETURN
specified by SystemV ABI for AMD64
Compatibility with other JITs
- All new GCInfo generated by RYU Jit is in GcInfo version 2
- All Ngen images must be regenerated with the new GcInfo version.
- Ready-to-run images with old GcInfo will continue to work.
- Jit64/X64 uses the GcInfo library, so it generates GcInfo version 2.
However, it doesn't (yet) provide the data to encode the correct ReturnKind
Similar is the case for ARM32 code running on JIT32, and any other JITs
that may be using GcInfo library but not yet modified to use the new API.
So, compatibility is achived using RT_Unset flag.
When ReturnKind is RT_Unset, it means that the JIT did not set
the ReturnKind in the GCInfo, and therefore the VM cannot rely on it,
and must use other mechanisms (similar to GcInfo ver 1) to determine
the Return type's GC information.
Implement GC root scanning for Hijack-frames
This change implements GCScanRoots() method for Hijacke-frames
based on the ReturnKind information available from the GcInfo.
If the exact ReturnKind is not available in the GcInfo, the
thread-suspension logic will compute the ReturnKind based on
the method-signature.
As a result of this change, several hijack-helpers in the VM
are cleaned up. There's only one implementation of HijackWorker()
to handle all returnKinds.
This change also simplifies the thread-hijack logic by using a
single assembly helper OnHijackTripThread() in most cases.
The only other helper used is for X86 floating point return values
for save/restoring the top of the FP stack.
ARM64
Only GcIndfo v2 is reliably supported for ARM64 platform.
The changes to thread-hijack mechanism fixes #6494 for ARM64.
No measurable change in JIT throughput, performance or native-image
size from this change.
|
|
This change removes the redundant set of GcInfo encoder/decoder
in the CoreCLR tree called Debug encoder/decoders.
These components are expected to be are well-tested versions
for verification, but are not actively used.
They cause additional overhead wrt maintaining two versions of
GcInfo encoder/decoder as GcInfo format changes.
|
|
This change enables the VM to support multiple versions GCInfo concurrently.
This is necessary in light of upcoming work to add ReturnType and other
modifications to the GCInfo format -- so that existing ReadyToRun images
will continue to run correctly.
The version# is not stored in the GcInfo structure -- because it is
wasteful to store the version once for every method. Instead, it is
tracked per range-section of generated/loaded methods.
The GCInfo version is computed as:
1) The current GCINFO_VERSION for JITted and Ngened images
2) A function of the Ready-to-run major version stored in READYTORUN_HEADER
for ready-to-run images. ReadyToRunJitManager::JitTokenToGCInfoVersion()
provides the GcInfo version for any Method. Currently, there's only one
version of GCInfo.
An abstraction GCInfoToken is added to the GcInfo interface, which tracks the
{GcInfo, Version} pair in-memory. Several GcInfo APIs are
modified to use GCInfoToken in place of GcInfo pointers.
Notes:
1) SOS GcDump: The GCDump API has separate dump routines for Header and the
pointer-liveness information (DumpGCTable and DumpGCHeader) each of which
advance a pointer to the GCInfo block. These APIs are not changed to
recieve a GCInfoToken in place of the GcInfo block pointer. Instead, they
recieve the GcInfo version at the time of construction.
2) Some routines that are specific to x86 gcInfo (ex: crackMethodInfoHdr)
are not yet updated to use versioning, since the development plan is to
update the Non-x86 GcInfo structure first.
3) The x86 specific structs defining GcInfo headers are moved to GcInfoTypes.h,
along with the non-x86 GcInfo type definitions.
|
|
|
|
ARM64: Fix GC encoding settings
|
|
This change fixes certain settings in the GCInfo encoder/decoders.
It also fixes the debug info for the stack pointer.
|
|
Currently only enabled for arm64
|
|
This required two other minor changes:
- A prototype for `ThrowOutOfMemory` is now defined in gcinfoencoder.h
- `BitArray` now defines an overload of `operator new` that accepts an
`IAllocator`.
|
|
This will allow the GC info encoder and the JIT to use this
function without pulling in the entire utilcode header.
|
|
- Encapsulate link management into `MemoryBlockDescList`.
- Replace `MemoryBlockDesc` and its separately-allocated buffer
with a new type, `MemoryBlock`, that stores the link to the
next memory block with the buffer itself.
|
|
Instead of using `SList`, manage the links manually. There are only
a few list manipulations in the encoders, so this is not too onerous.
|
|
Refactor `StructArrayList` for the GC info encoder.
|
|
- Move the code into the GC info encoder, as that is its
only consumer.
- Remove contracts
- Delete dead code
- Reformat and refactor to current coding standards
|
|
GCStress traps were not inserted in ARM64 code correctly because safepoint
offsets were not correctly computed by EnumerateSafepoints().
This change fixes the issue by adding the (-1) adjustment to the ARM64
Safepoint offsets, similar to ARM and AMD64.
|
|
This removes another utilcode dependency from the GC info encoders.
|
|
These behaviors override the default out-of-memory handling
s.t. it is appropriate for the JIT.
|
|
This mainly involved DACizing the VM code.
A bulk edit for changing RUNTIME_FUNCTION to T_RUNTIME_FUNCTION
[tfs-changeset: 1591667]
|
|
- Delete BINDER, STANDALONE_BINDER and MDIL ifdefs
|
|
There are a number of macros, method bodies, and type definitions that
do not need to be in gcinfoencoder.h. Instead, these definitions have
been moved into gcinfoencoder.cpp.
|
|
|
|
Conflicts:
build.cmd
src/dlls/clretwrc/CMakeLists.txt
Cleanup
|
|
Some places already use ARCH_SOURCES_DIR for things like include_directories but others test the platform/arch variables to figure out the dir. Use ARCH_SOURCES_DIR everywhere for consistency.
|
|
Fixed some C++ warnings that are treated as errors when compiling
LLILC.
|
|
[tfs-changeset: 1550765]
|
|
This change replaces DWORD, LONGLONG, ULONGLONG, SIZE_T, BYTE, LONG32 and few more by
standard c++ types. The DWORD still remains present in signatures of Windows APIs used
by the GC. There are few issues with those that need to get fixed.
|
|
When building llilc against coreclr in Linux, m_IsSlotTableFrozen is defined under _DEBUG
but it is used without guard "#ifdef _DEBUG"
This is fix for it.
|
|
Add fake uses for two variables referenced only in asserts.
|
|
This allows building the Windows x86 version of CoreCLR by using "x86" for the BuildArch parameter of build.cmd. Note that CMAKE_SYSTEM_PROCESSOR is no longer used in Windows builds to set IS_64BIT_BUILD.
This change is enough to get CoreCLR to build but more changes are required for it to actually run correctly. In particular, the JIT compiler support for x86 is pretty limited at this point.
|
|
Remove three unused local variable definitions --
which caused warnings in the LLILC build.
|
|
|
|
The STANDALONE_BUILD switch can be used to build the GcInfoEncoder library
independently by clients outside the CoreClr tree.
The GcInfo library uses some custom data-structures (ex: ArrayList)
and includes some utility libraries (ex: UtilCode) which pull in several other
headers with considerable unrelated content. Rather than porting all the
utility code to suite other clients, the STANDALONE_BUILD switch can be used
to include only the minimal set of headers specific to GcInfo encodings.
Clients of STANDALONE_BUILD will likely use standard library
implementations of data-structures like ArrayList, HashMap etc., in place
of the custom implementation currently used by GcInfoEncoder.
Rather than spew the GcInfoEnoder code with
#ifdef STANDALONE_BUILD ... #else .. #endif blocks, we include a special
header GcInfoUtil.h in STANDALONE_BUILD mode. GcInfoUtil.h is expected to
supply the interface/implementation for the data-structures and utilities
used by GcInfoEncoder. This header should be provided by the clients doing
the standalone build in their source tree.
|
|
- Crossgen is now built as part of coreclr
- Crossgen successfully compiles mscorlib.dll
- Resulting mscorlib.ni.dll not yet usable
|
|
Adds and modifies CMakeLists.txt files to enable building of crossgen.exe from build.cmd for x64 processor on Windows. Also adds a step in build.cmd to generate native image for mscorlib.
[tfs-changeset: 1456454]
|
|
|
|
[tfs-changeset: 1407945]
|
