| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Run code under long paths on Unix
|
|
This change allows the happy path for a simple corerun Hello World app.
This is pretty close to the bare minimum needed to run.
Adds a MAX_LONGPATH define for long paths and MAX_PATH_FNAME to use for
places where MAX_PATH is used for something that is trully 260 characters
(usually file names).
|
|
(Port changeset 1518001 from CodeGen)
The bug occurs when fgOptWhileLoop() duplicates a condition from one 'try' region into another, and that condition throws an exception, such as for an array bounds check. This was the test case:
try
{
Console.WriteLine("try");
}
catch (IndexOutOfRangeException)
{
Console.WriteLine("bad");
result = FAIL;
}
while (a[42] != 0) {}
Before the fix, the "a[42] != 0" condition was duplicated into the 'try' region, thus causing an IndexOutOfRange exception to be thrown, and caught in the wrong region.
The main fix is to compare the 'try' region of the region where the condition exists and the region we intend to copy it to. The other changes, in optimizer.cpp and flowgraph.cpp, are "defense in depth" -- to be more careful with EH checks in two very similar optimizations.
This bug existed in AMD64 and ARM32.
There are 2 functions with ARM32 asm diffs.
There are 70 functions with AMD64 SuperAsm diffs.
There are many cases where we prohibit the optimization that caused the bug. There are a few cases where we don't do the optimization but could have if we were more careful about checking for precise EH conditions that are allowed, namely, that branching to the first block of a 'try' region is ok.
[tfs-changeset: 1518014]
|
|
Enable gcroot and other gc related sos commands.
|
|
The "gcroot" command currently doesn't work with lldb 3.6 (our default package), but
works fine with lldb 3.7.0.
lldb 3.6 terminates with
(lldb) sos GCRoot 00007fffcc004ce8
*** Error in `lldb-3.6': munmap_chunk(): invalid pointer: 0x000000000184cde8 ***
PAL_STDCPP_COMPAT is the define that the VS team added to allow the xplat
headers to be used. This is neccessary for the whole SOS directory now
because gcroot and other gc commands need unorderd_map, unorderd_set, etc.
from the stdlib.
Had to change all wchar_t to WCHAR because the xplat stdlib default is UTF32.
Had to rename and provide macros that conflict with the stdlib:
wcslen -> _wcslen
wcsncmp -> _wcsncmp
wcsrchr -> _wcsrchr
wcscmp -> _wcscmp
wcschr -> _wcschr
wcscspn -> _wcscspn
wcscat -> _wcscat
__in -> ___in
__out -> ___out
max(a, b) -> _max(a, b)
min(a, b) -> _min(a, b)
Had to ifdef PAL_STDCPP_COMPAT a lot more of pal.h, palrt.h and some other header files.
Changed a bunch of L"" to W("").
|
|
Some use cases of CoreCLR require overriding the assembly load context,
triggering this assertion. However, this override does not necessarily
break support of BindByWhereRef, and so it should be attempted on a
best-effort basis, instead of bailing out prematurely.
|
|
Auto-detect VS2015
|
|
VS2015 optimizer is smart enough to optimize out stores into globals that are only read by the DAC.
|
|
Add CORINFO_CALLINFO_ATYPICAL_CALLSITE flag to JIT-EE interface
|
|
|
|
Fix timing in more PAL tests for FreeBSD on hypervisors
|
|
Update buildtools version to fix VS2015 build
|
|
|
|
Required by VS2015
|
|
Remove PAL code that has been moved to the corefx repo
|
|
CORINFO_CALLINFO_ATYPICAL_CALLSITE is meant to be used in situations where the code generator cannot guarantee that the callsite can be disassembled by delay load helper (e.g. it is not call [rel32] on x86/x64)
|
|
|
|
Handle newer tzfiles by allowing for the "big bang" transition.
|
|
In the TZ release 2014c, a new "big bang" transition time was added
to the beginning of the tzfiles. This broke the TimeZoneInfo parsing
logic because the transition time was for 13 billion years ago, which
is unrepresentable by DateTime.
To handle these new transitions, check for times really far in the past and future, and use DateTime.Min/Max to represent them. Then skip over any DateTime.MinValue times when generating the AdjustmentRules.
Fix https://github.com/dotnet/corefx/issues/2816.
|
|
TimeZoneInfo.IsAdjustmentRuleValid is no longer using the "dateOnly/whole-date" portion on Windows to check for the correct AdjustmentRule. This causes problems when converting times and determining if a time is daylight savings or not.
Fix https://github.com/dotnet/corefx/issues/2821
|
|
Build mscorlib on linux
|
|
Initial work to get mscorlib.dll building via Roslyn + MSBuild running
on top of Mono on Linux.
- Use a newer version of BclRewriter.exe which works cross-platform,
the major difference here is that now we need to specify the input
assembly as a named argument instead (since fully qualified paths on
Unix look like flags on Windows).
- The ResGen we use comes from Mono, which does not support the -d
flag, so we need to stop passing defines to ResGen. I know the mono
folks recently did some work to address this, but long term we need
to move towards getting our ResGen.exe running on CoreCLR and use
that instead.
- Don't require that mono is installed in order to build coreclr. If
mono is not on the path, skip the build step to enable folks to do
development without Mono. In this case, they will need to continue
to build mscorlib.dll on Windows, targeting Unix.
- Mono stability has been an issue for folks that have buddy tested
this. I've found that recent mono 4.2 builds, when run with the
Boehm GC work well for me. Other folks have other builds they like
instead. The `skipmscorlib` flag can be passed to build.sh if you
want to skip building mscorlib.dll locally.
|
|
StackTrace_Stack was conditional between Unix and Windows, which is
problematic when building on Unix, since the Mono provided ResGen does
not understand our define directives. It turns out this string is
unused (in both CoreCLR and Desktop) so to make things easier, we can
just remove it.
|
|
It has been replaced by stat shims in corefx System.Native.
Reverts commits:
* 79ebe5605a94d559d2996997aec3cbcf8a4504c3.
* 0119283384f1bac80da8bb1736453c87d4f8e689.
|
|
Remove incorrect msbuild logic for creating relative paths
|
|
method that had the SecuritySafeCritical attribute but it does not have the attribute itself.
This change adds the attribute to the new method.
[tfs-changeset: 1514941]
|
|
Make use of TimeZoneInfo.CachedData on Linux.
|
|
Fix https://github.com/dotnet/corefx/issues/2497.
|
|
Rebuild the resource file when the input file changes
|
|
Mostly just in comments, test case and trace text, but the exception
thrown if you try to GetInterfaceMap on an array type has it in
the description.
|
|
The logic was using Link to try and show mscorlib sources show up in VS.
Turns out the logic was both incorrect and not needed.
|
|
When building mscorlib resources we are not taking into account the file
that contains the resource strings when deciding if we need to rebuild the
resources file.
Becasue of this, adding/modifying a resource string will not show up in the
build resource file until you delete the intermediate folder.
|
|
Throw PlatformNotSupported for named sync primitives on Unix
|
|
libcoreclr's synchronization primitives implementation currently supports names, but those names have process-wide rather than system-wide scope. This is very dangerous for most code that would want names, as they're typically used for cross-process synchronization, and as such the current behavior could lead to bad race conditions difficult to diagnose. Until a better solution is available, we will throw PlatformNotSupportedException when trying to create such named primitives.
|
|
(Interop\WinRT\Exception\ManagedClientNativeServer\ExceptionTest.csproj).
The test checks that the HResult 0x8000000e maps to a System.InvalidOperationException.
What was happening: We returned a System.COMException with the message "A method was called at an unexpected time." (we're just constructing an exception based on an HR message).
What should be happening: We return a System.InvalidOperationException (i.e. we check against the exceptionKind maps for a specific HResult to map to an exception).
The point of failure is in the creation of the EEMessageException. When calling GetKindFromHR(...) we were inverting the boolean that uses the WinRT mappings.
Removing that inversion allows us to check the WinRT Exception Maps for exceptions. When I made this change, we correctly return the correct Exception.
Test coverage: I ran a full DDR, and the whole TOF (both against my build and against the newest build). All passed successfully (i.e. no additional failures).
[tfs-changeset: 1514327]
|
|
Fix GC issues during exception handling on Unix
|
|
This change fixes two issues that happens in some cases when GC scans stack of
a thread that is handling exception at that moment.
First issue was caused by the fact that the stack walker wasn't modified to
take into account the difference in exception handling on Unix. When an exception
is thrown from a catch handler or finally block (a funclet )on Unix, part of the stack
is unwound immediatelly, while on Windows, the stack is not reclaimed until
the exception is fully handled.
The problem was caused by the fact that when GC happens in the funclet before the exception
is processed, but after a point where GC knows that the lifetime of locals in the caller frame
is over, it doesn't update the references in the caller frame for objects that it has relocated.
On Windows, this is detected just from walking the stack, since the funclet frame is still there
and the stack walker can then skip scanning the parent frame GC references.
On Linux, the funclet is not on stack anymore, so this case was not detected and GC attempted to
scan the stale references and crashed.
The fix was to detect that a frame was a caller to a funclet from the chain of previous exception
trackers that is fortunately preserved and the trackers hold the necessary information.
The second issue was more subtle. During interleaved exception handling, when we unwind a native
portion of the stack and switch back to unwinding a managed block of stack frames, we re-create
the exception tracker and carry over just a few members necessary to continue processing the
same exception. The way it was done was that we have first removed the current tracker from
the list of trackers of the current thread, then we have destroyed it, created a new one and
put it back to the front of the list.
The issue happened when GC started walking the stack of the thread in the small time slot when
the current tracker was removed from the list, but the re-created tracker was not added there yet.
Then the detection necessary for handling the previous issue didn't work and we got a crash.
The fix was to make the whole re-creation of the exception tracker atomic w.r.t. the GC.
|
|
type when building mscorlib.
[tfs-changeset: 1513902]
|
|
We need this so we can get a signed build of BclRewriter.exe which is only produced by the offical build out of the ProjectK branch.
[tfs-changeset: 1513878]
|
|
This change is fixing the DateTime parser in cases of date/time strings for cultures which has the date and time separators are same. This happen with Norway, Serbia and Finland cultures
[tfs-changeset: 1513801]
|
|
Fix a bug with disappeared cast to byte in numeric binary expressions
|
|
Lowering::IndirsAreEquivalent doesn't check if the 2 indirections have the same type and because of that a RMW style instruction is generated instead of the expected
movzx rax, byte ptr [7FFA61024742h]
xor eax, 33
mov word ptr [7FFA61024742h], ax
This behavior was fixed by adding an additional check to IndirsAreEquivalent (implementation of the mikedn's approach: https://github.com/dotnet/coreclr/pull/1329#discussion_r36397171).
Fix #1323.
|
|
Implementing GetSystemTimeZones on Linux by reading
the zone.tab file on the machine, parsing out the
valid TimeZone IDs from it, and using those Ids to read
all the time zones on the machine.
|
|
Assorted fixes for VS2015 build breaks
|
|
|
|
TimeZoneInfo parse v2 tzfile and create AdjustmentRules
|
|
TimeZoneInfo on Linux needs to parse V2 tzfile information and
correctly create AdjustmentRule instances based on the tzfile
information.
To create AdjustmentRules correctly, I introduced a new flag on
AdjustmentRule - NoDaylightTransitions, which means the adjustment
is fixed for the whole time the rule is in effect. This allows
us to create an AdjustmentRule for each time the offset changed
in a time zone (whether the change was for Daylight Savings or
for some other reason). I also needed to relax the rule that
DateStart and DateEnd needed to be DateTimeKind.Unspecified.
Instead, when we create NoDaylightTransitions adjustment rules
in Linux, we use DateStart and DateEnd to be UTC times the offset
transitioned.
Fix #2465.
|
|
[tfs-changeset: 1512604]
|
|
[tfs-changeset: 1512590]
|
