| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
ARM32-target (#8687)
* fix CMakeLists.txt for palrt
* Modify CMakeLists.txt for cross-architecture component configuaration
Add coreclrpal project to fix a dependency issue when CMake configuration
* Allow only x64-host/arm-target for linux
allow x64-host/arm-target only, because pal is not stable for x86 now
* Update build.sh
delete NumProc=1 (inserted for debugging)
* Change x64-host to x86-host for arm-target
JIT correctness problem,
and fix CMake configuration for x86 in pal
* Fix type
* Update CMakeLists.txt
* fix style
* Set x86 when arm-target/x64-host
* fix typo
|
|
This feature is always defined and the PAL functions that would be used
if the feature was not defined are not in PAL anymore.
|
|
|
|
Ifdef more unused code that uses ReadProcessMemory. Move the current
memory probing in the transport to PAL_ProbeMemory. Add PAL_ProbeMemory
to dac PAL exports.
PAL_ProbeMemory may be changed to use write/read on a pipe to
validate the memory as soon as we make it perform as well as
the current code.
Remove ReadProcessMemory tests and add PAL_ProbeMemory pal tests.
|
|
(#8673)
Port of https://github.com/dotnet/corert/issues/2377
|
|
* Fix buildsystem for linux cross-architecture component build
* refactoring build.sh, bug fix and typo fix
* Update build.sh
|
|
Clang (and GCC) requires 16-byte stack alignment, but the current
implementation of CallDescrInternal and ThePreStub does not provide any
guarantee on stack alignment.
This commit adds 16-byte stack alignment adjust code inside these functions.
|
|
In x86/Linux, __fastcall is defined as __stdcall which causes stack
corruption issue for the following functions:
- HelperMethodFrameRestoreState
- LazyMachStateCaptureState
This commit removes __fastcall definition as clang recognize __fastcall.
|
|
* [x86/Linux] Port jithelp.asm
This commit ports jithelp.asm for x86/Linux
The following Tailcall helpers are marked as NYI:
- JIT_TailCall
- JIT_TailCallReturnFromVSD
- JIT_TailCallVSDLeave
- JIT_TailCallLeave
* Revise macro and indentation
|
|
Fix unit test error for x86/Linux
- fix fail of exception_handling/pal_sxs/test1/paltest_pal_sxs_test1
|
|
* [x86/Linux] Revise asmhelper.S using macro
This commit revises asmhelper.S using macros that inserts CFI
directives.
|
|
* Remove sscanf
* Remove sprintf
|
|
Fix building against liblttng-ust-dev 2.8+
|
|
|
|
|
|
|
|
CONTEXT struct for ARM64 does not contain X29 field.
|
|
|
|
specified (#8340)
|
|
* (Partially) Enable x86/Linux PAL
* Fix personality routine address encoding
* Fix build warnings
|
|
Also fixed checking of context flags on OSX (issue #8116)
|
|
This change fixes the problem where scanelf tool reported that libcoreclr.s
contains TEXTRELs, however it was unable to find any.
It turns out there actually were TEXTRELs, but not in the program code or
program data, but rather in the DWARF tables. The NESTED_ENTRY macro for
ARM64 and AMD64 uses .cfi_personality with encoding 0, which means
absolute address. This is the source of the TEXTREL.
Changing the encoding to 0x1b - DW_EH_PE_pcrel | DW_EH_PE_sdata4 fixes the
problem - the scanelf tool no longer reports any TEXTRELs in libcoreclr.so.
|
|
There were few constructs that Clang 3.9 didn't like due to its strict
C++ standard conformance rules.
|
|
The files in src/pal/src/arch/i386 are actually for amd64 (not x86).
This commit renames the directory name as the first step towards
enabling PAL in x86/Linux.
|
|
|
|
|
|
Fix compile error for x86/Linux
- add ASSIGN_UNWIND_REGS in seh-unwind.cpp for x86
- add CONTEXT_EXCEPTION_ACTIVE in pal.h for x86
- add CONTEXT_XSTATE in pal.h for x86
|
|
WIP, fix compile error for x86/Linux
- add directive WIN32 to current DISPATCHER_CONTEXT in clrnt.h
- add DISPATCHER_CONTEXT for x86 in palrt.h
|
|
Fix compile error for x86/Linux
- fix calling convention by adding PALAPI to TerminationRequestHandlingRoutine
|
|
WIP, fix compile error for x86/Linux
- fix to use STDMETHODVCALLTYPE
|
|
[x86/Linux] Fix compilation in pal and context header
|
|
This patch will add x86 part for cross build
- add x86 in build-rootfs and related cross files
- add x86 parts in CMakeLists.txt to pass configuration
- add required source files to pass configuration
|
|
WIP, fix compile error for x86/Linux
- add KNONVOLATILE_CONTEXT_POINTERS
- add _X86_ codes in pal/context.h
|
|
This change removes _snwprintf, _snprintf and _vsnwprintf usage from CoreCLR and
their implementations from PAL.
PAL exposes their secure variants instead and CoreCLR now uses those instead.
I have also removed the StringCchPrintfA/W, StringCchVPrintfA/W, StringCbVPrintfA/W,
StringCbPrintfA/W, StringCbPrintfExA/W, StringCchVPrintfExA/W, StringCbVPrintfExA/W
and StringCchPrintfExA/W replaced their usage by the secure variants of the sprintf
functions, since they were used at only few places and implementing all of the variants
using the secure sprintf variants would be a hassle.
I also needed to fix a missing support for size modifiers for %p formatting character
and for wide characters / strings in the secure sprintf functions that was revealed
by the PAL tests.
I have also removed a bunch of PAL tests that were using %n formatting character which
was not implemented since it is considered unsafe and translated PAL tests that were using
the removed functions to use the safe variants of those.
|
|
|
|
On x64, JIT can generate code that uses all 16 xmm registers.
However, on Mac OSX, we currently only save 8 of these registers.
Thus after a context save/restore, xmm8 through xmm15 are
corrupted. This commit fixes the code to save all 16 xmm
registers. It resolves issue #2266.
|
|
This change removes the following PAL functions and their related PAL tests:
_i64tow
_itow
lstrcatW
lstrcpyW
wsprintfA
wsprintfW
lstrcpynW
The lstrcpynW was actually used in two functions in palrt and I have replaced it
with StringCchCopyNW.
The _i64tow and _itow were used as an implementation of the _i64tow_s and _itow_s.
Since these _s versions were also implemented in PAL for its internal purposes,
I have exposed them and got rid of the unsafe versions.
|
|
|
|
This change removes some unused PAL functions and the corresponding PAL tests.
|
|
Expose GlobalMemoryStatusEx on Xplat
|
|
Add LCG JIT Compilation Profiler Callbacks
|
|
|
|
|
|
Methods that contain no metadata (e.g. of sources are IL Stubs,
DynamicMethod, Expression Trees, etc.) also known as LCG methods are not
reported to profilers via the Profiling API. LCG, introduced in .NET 2.0
timeframe is unique in that it doesn't require the method to be hosted
in an assembly > module > type heirarchy and is GCable in of itself.
This change adds new APIs that notify the profiler of such methods but
since there is no metadata to go lookup, it provides some useful pieces
of information that the profiler author may want to expose to the
profiler user.
In the compilation start method we provide a className (always
dynamicClass), a methodName that can be a set of few predetermined names
like (ILStub_COMToCLR, etc.) or if the user has set the name for the LCG
method that can show up here. For example, when using the Expression
Trees API, the user can specify a friendly name which would be returned
here.
In the jit completed callback we provide information for the native code
start address and size. This is particularly useful to get more accurate
accounting of what the (previously unidentified) code is. At least the
user would know it is JITTed if nothing more (but most likely more
information like what kind of stub).
Furthermore, since this is going to be a profiler callback, the profiler
can initiate a stackwalk and give more contextual information to its
users beyond the pieces of information we can provide here that could
identify what they're encountering.
Finally, there is also the case that today the profiling APIs
underreport JITTed code in the process. Considerable amount of LCG code
can now be present in the program and in security-sensitive environments
where tracking JITTed code for security reasons is important the
profiling apis fall short. In such environments there is also often
restrictions on running with elevated privileges, so procuring this data
through other means (like ETW) may pose a challenge.
|
|
* Adding single-precision math functions to floatsingle
* Adding single-precision math functions to the PAL layer.
* Adding single-precision math tests to the PAL layer.
* Adding single-precision math functions to mscorlib.
* Adding single-precision math function support to the vm.
* Updating floatsingle.cpp to define a _isnanf macro for Windows ARM.
|
|
This change fixes a memcpy #undef in the palinternal.h. It was undefed only for
non-debug builds, but it needs to be undefed for debug build as well. The non-debug
undef covers the case where memcpy is defined as DUMMY_memcpy, but doesn't cover
the debug case where memcpy is defined as PAL_memcpy.
|
|
* add typeID APIs
* add variable home API
|
|
This change enables build of CoreCLR on Alpine Linux. Here is the list
of changes:
- Disable asserts checking RSP in arbitrary threads against cached stack limit
for the respective thread. The stack on Alpine obviously grows over the limit
reported by the pthread functions.
- Disable using XSTATE. This should be re-enabled after MUSL gets the _xstate,
_fpx_sw_bytes and related data structures added to the signal.h header.
- Disable setting rlimit of RLIMIT_NOFILE to the max value, since it breaks
debugging for some reason.
- Add skipping over the hardware signal trampoline in the PAL_VirtualUnwind.
While we were not trying to walk over it in a simple case, in a case where
an exception was thrown from a catch handler of a hardware exception, we
still attempted to walk over it and it fails on Alpine.
- Fix detection of Alpine Linux in the PAL's CMakeLists.txt so that it works
in Docker containers too.
- Modified PAL_VirtualUnwind to make the check for unwinding past the bottom
of the stack unconditional. We had a long list of platforms where we were
doing this check and it doesn't hurt to do it on platforms where it is not
needed. I have done that rather than adding a check for Alpine Linux as
another platform that needs it.
|
|
|
|
executables on Nano Server (#7317)
Needed to add back a dummy version of ICorDebugLegacyNetCFHostCallbackInvoker_PrivateWindowsPhoneOnly interface so
VS doesn't get the QI failure and stop working by not calling the "Continue" method.
Issue #7316
|
