{"push_id":795127859,"size":44,"distinct_size":0,"ref":"refs/heads/master","head":"684abc9d00eedf984740cf7745621a3f75a62bbd","before":"059b6592a9bc1390a982f34a4a693a1159d7bd97","commits":[{"sha":"1bf2f97c89d58f2691b5c39ed58a6399cfef883a","author":{"email":"de2b83bd3e35329bad687cd114521673f3e438bb@microsoft.com","name":"Sridhar Periyasamy"},"message":"Build Code Coverage instrumented binaries for native bianries in Linux and OSX.\n\nAdd an option in build.sh called 'coverage' to produce gcov-style instrumented builds.\nExample usage - ./build.sh debug coverage clean\n\nThis will generate the '.gcno' notes files for each object file in the same directory along with the instrumented native binaries. These .gcno files contain some of the coverage data like source line mappings, basic block graphs info etc.\n\nEach time these instrumented binaries are run, a separate .gcda file is created for each object file in the same directory. These .gcda files contain arc transition counts, and some summary information.\n\nCode Coverage reports can be generated from the .gcno and .gcda files using a tool like gcovr or lcov. *But this commit is only for generated the .gcno files while compiling with the 'coverage' option.*\n\nThe next steps\n - Add option in run-test.sh to generate code-coverage reports using the instrumented native binaries.\n - Integrate with Jenkins CI to do code-coverage runs.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/1bf2f97c89d58f2691b5c39ed58a6399cfef883a"},{"sha":"c3ff9cae6fb311685740f92635f837f5e448d09e","author":{"email":"c457b3e5195ce3a91c472dc392bcc90fb508bb62@microsoft.com","name":"Jan Vorlicek"},"message":"Fix memory leak from managed exceptions\n\nHandling thrown PAL_SEHException was causing leaks for all exceptions thrown due to\ntwo aspects:\n1) PAL_GetStackBase() and PAL_GetStackLimit() were missing calls to pthread_attr_destroy()\n2) We were calling the DispatchManagedException from C++ catch handlers and this function\n   never returns. So the C++ exception handling never called __cxa_end_catch that is\n   responsible for freeing the exception storage allocated by the C++ runtime.\nThe fix to the 2nd aspect was to store a copy of the exception in the catch handler, let it\ncomplete and then call the DispatchManagedException with the copy. It was also necessary to\nslightly modify the unwinding of sequences of native frames since there is now no rethrowable\nexception and the StartUnwindingManagedFrames has to throw a new one.\nThis change has a secondary benefit - the StartUnwindingManagedFrames no longer calls\n__cxa_rethrow, but rather a helper C++ function that uses regular \"throw\" keyword.\nThat makes the code more portable.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/c3ff9cae6fb311685740f92635f837f5e448d09e"},{"sha":"49467db25402d39179a610c15b2c35c3622b4637","author":{"email":"a96234fe51920ba0e9a34bfce5dcb85e5c8dcdcd@microsoft.com","name":"Eugene Rozenfeld"},"message":"Add mappings for ReadyToRun helpers used by llilc:\nREADYTORUN_HELPER_ThrowNullRef and READYTORUN_HELPER_ThrowDivZero.\n\nAllow ReadyToRun tests to be run with llilc.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/49467db25402d39179a610c15b2c35c3622b4637"},{"sha":"f4501e1ff7ae464f1ade593a1ba463fdbe7ec5b1","author":{"email":"73675debcd8a436be48ec22211dcf44fe0df0a64@curlybracket.co.uk","name":"Ben Pye"},"message":"Fixes ARM Strike build","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/f4501e1ff7ae464f1ade593a1ba463fdbe7ec5b1"},{"sha":"22ba538463bcc08eff108a4290f655596536b0c6","author":{"email":"fa77123c115913ca9e97c82fc48a0b47e477b7b4@microsoft.com","name":"Mike McLaughlin"},"message":"Fix debugger/debuggee connection on OSx.\n\nThe reason there were problems connecting on OS X was that the read\non the debugger/debuggee pipe didn't return the full number of bytes\nrequested on the first read. There are times (depending on the size\nof the read request) that multiple reads to be made to get all the\nbytes requested. This change adds code to retry the read or write\nuntil all the bytes requested are read or written.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/22ba538463bcc08eff108a4290f655596536b0c6"},{"sha":"7c7d58d3b1b1ba6d70e41ad22c77b11ed428c5b9","author":{"email":"c457b3e5195ce3a91c472dc392bcc90fb508bb62@microsoft.com","name":"Jan Vorlicek"},"message":"Fix managed exception dispatching\n\nThe managed exception dispatching is initiated from the UNINSTALL_MANAGED_EXCEPTION_DISPATCHER\nmacro and it should be used only at the border between managed and native code, when managed\ncode calls native one. This macro is part of the UNINSTALL_UNWIND_AND_CONTINUE_HANDLER_NO_PROBE\nmacro. However, it turns out that the UNINSTALL_UNWIND_AND_CONTINUE_HANDLER_NO_PROBE\n(or the UNINSTALL_UNWIND_AND_CONTINUE_HANDLER that uses it) is also used at places where\nthere is no managed / native border. In that case, the managed dispatching results incorrectly\nin skipping native frames that would otherwise handle the exception.\n\nThe fix removes the INSTALL_MANAGED_EXCEPTION_DISPATCHER / UNINSTALL_MANAGED_EXCEPTION_DISPATCHER\nfrom the INSTALL_UNWIND_AND_CONTINUE_HANDLER_NO_PROBE / UNINSTALL_UNWIND_AND_CONTINUE_HANDLER_NO_PROBE\nand puts them to specific places where INSTALL_UNWIND_AND_CONTINUE_HANDLER_NO_PROBE /\nUNINSTALL_UNWIND_AND_CONTINUE_HANDLER_NO_PROBE and INSTALL_UNWIND_AND_CONTINUE_HANDLER /\nUNINSTALL_UNWIND_AND_CONTINUE_HANDLER are used at the border between managed and native code.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/7c7d58d3b1b1ba6d70e41ad22c77b11ed428c5b9"},{"sha":"9774e45949686bdda3e99652218243bd677e2e09","author":{"email":"c457b3e5195ce3a91c472dc392bcc90fb508bb62@microsoft.com","name":"Jan Vorlicek"},"message":"Remove FuncEvalHijackPersonalityRoutine for PAL\n\nThe personality routine on Windows is responsible for redirecting exception unwinding\nto a different context when function evaluation is injected into a managed thread and\nthere is an exception that escapes the evaluation. However, the FuncEvalHijackRealWorker\ncatches all exceptions that happen during the function evaluation, so nothing should\nescape.\nMoreover, if anything escaped, it would go to the original hijacked code which is not\nexpected.\nSo I am replacing the personality routine for PAL with UnhandledExceptionHandlerUnix\nto guard against unexpected exception escaping.\n\nI am also setting the same personality routine to the ExceptionHijack function. Some\ntime ago, it was removed completely there as a temporary fix for a problem with limited\nmax number of personality routines in single executable. I have looked at it\nagain and I can see that no exception should escape the ExceptionHijackWorker either and\nso the same thing as for FuncEvalHijack applies for ExceptionHijack too.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/9774e45949686bdda3e99652218243bd677e2e09"},{"sha":"df62c661c04ae352ba905318c8e22b7dede65c7d","author":{"email":"de2b83bd3e35329bad687cd114521673f3e438bb@microsoft.com","name":"Sridhar Periyasamy"},"message":"Change warning to error for platforms not supporting code coverage at this time. This is make sure that the warning does not get accidently swallowed at some point in the future.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/df62c661c04ae352ba905318c8e22b7dede65c7d"},{"sha":"72de8c3d8a7c2e0382d253dee14ebb19f2b137d9","author":{"email":"d5217de2cb6752de988d48d59f950ae57a90ca04@microsoft.com","name":"Aditya Mandaleeka"},"message":"Fix the remaining unused variable/label warnings","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/72de8c3d8a7c2e0382d253dee14ebb19f2b137d9"},{"sha":"c5b77a242e87e58ea2b0745270e9202580ac2787","author":{"email":"c457b3e5195ce3a91c472dc392bcc90fb508bb62@microsoft.com","name":"Jan Vorlicek"},"message":"Fix missing uses of the INSTALL_MANAGED_EXCEPTION_DISPATCHER\n\nThis fixes issues stemming from my recent changes in managed exception dispatching\nwhere I have missed few places where we need to perform managed exception dispatching\nor unhandled exception reporting.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/c5b77a242e87e58ea2b0745270e9202580ac2787"},{"sha":"5ef647b08a84f24abb8e2a89536f832debd041a0","author":{"email":"be3f36b6fbce8d4f7a4d47e3a7c547c7aadb94e3@microsoft.com","name":"Lakshmi Priya Sekar"},"message":"Replace MAX_PATH with new defines, rest of coreclr.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/5ef647b08a84f24abb8e2a89536f832debd041a0"},{"sha":"412ffb447a2dbbd5aa78f7c49006759858e72d4e","author":{"email":"c457b3e5195ce3a91c472dc392bcc90fb508bb62@microsoft.com","name":"Jan Vorlicek"},"message":"Fix printf formatting for ll, I and I32 length modifiers\n\nThese modifiers were not handled at all.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/412ffb447a2dbbd5aa78f7c49006759858e72d4e"},{"sha":"b4e7ad981a4b0ed40e4eb1ce74c1b8a452ffdf43","author":{"email":"c457b3e5195ce3a91c472dc392bcc90fb508bb62@microsoft.com","name":"Jan Vorlicek"},"message":"Reflect PR feedback","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/b4e7ad981a4b0ed40e4eb1ce74c1b8a452ffdf43"},{"sha":"b2274297f6ed0108b67e6c91955d55ed6de9c4de","author":{"email":"3df4de904f51eac4b4509e077cfbdce18458dd54@inbox.ru","name":"sergey-raevskiy"},"message":"Clarify comment","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/b2274297f6ed0108b67e6c91955d55ed6de9c4de"},{"sha":"b487cd5728448423b551f9e6b739ca0bb964d279","author":{"email":"79c8506aa7c4f256d586135507aa979186135502@microsoft.com","name":"Koundinya Veluri"},"message":"Allow loading assemblies on the TPA list without specifying a version\n\nWhen comparing the bound assembly's version against the requested assembly name, removed the distinction between platform\nassemblies and app assemblies when the bound assembly is on the TPA list. A requested version of null behaves equivalently to\na requested version of 0.0.0.0.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/b487cd5728448423b551f9e6b739ca0bb964d279"},{"sha":"60e60591eff56aeaae058609547e6ab04c6dfaaa","author":{"email":"79c8506aa7c4f256d586135507aa979186135502@microsoft.com","name":"Koundinya Veluri"},"message":"Add AssemblyExtensions.TryGetRawMetadata to the System.Reflection.Metadata namespace.\n\nThis patch contains has the necessary changes in coreclr and mscorlib. Tests will be added separately, once the new API is\npublished and can be consumed.\n\nPart of dotnet/corefx#2768","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/60e60591eff56aeaae058609547e6ab04c6dfaaa"},{"sha":"5c11731874b55ed9fb6aea28349238a27d7b1633","author":{"email":"de2b83bd3e35329bad687cd114521673f3e438bb@microsoft.com","name":"Sridhar Periyasamy"},"message":"Address code coverage builds feedback\n\n- Move the build type check to unix only.\n- Remove the global fPIC compiler option and add it as compile flags for libcorguids @ src/inc/CMakeLists.txt\n- Use add_compiler_options instead of add_definitions.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/5c11731874b55ed9fb6aea28349238a27d7b1633"},{"sha":"40cca8c8e8bf5a8bf8da311e8de731691855d3b1","author":{"email":"0860b8a6340f342d485aedfa6c3a5e66d61d0e15@microsoft.com","name":"Venkata Sivaramakrishna Ramadugu"},"message":"Fix to correctly spill a special putarg_reg when the fixed register assigned to it is getting killed before its GT_CALL.\n\nEssentially in execution order we have the following nodes\n\n     RCX <-- GT_PUTARG_REG(lcl var V07)  here V07 is 'this' object\n     R8 <-- GT_PUTARG_REG(GT_AND(GT_LSH,...))\n     ControlExpr of call (i.e. call target) is a vtable call and uses 'this' object to get to the right virtual method. Essentially a GT_IND(GT_LEA(V07))\n     GT_CALL\n\nWhile building ref positions for first putarg_reg, it is flagged as \"special\" and preferenced to its source lcl var V07 if it is the non-last use.   The hope is that if there are further uses of V07 before the kill of fixed reg assigned to V07, they can continue to be in that register.\nWhile allocating a register to a special putarg_reg, lsra checks that a) source lcl var's interval is active and b) register assigned to source lcl var is the same as putarg_reg\n\nSecond putarg_reg (to R8) has an operand which needs CL (shift operation) and hence will kill RCX before GT_CALL. As a result, V07 is marked for spilling after its use in special putarg_reg but not first putarg_reg.  Further since next kill of RCX (GT_LSH) is well before the next use of source lcl var (in controlExpr), putarg_reg cannot be marked as isBusyUntilNextKill.  As a result, LSRA would think that RCX is available for allocation after the last use of V07 in controlExpr and hence GT_IND is allocated RCX thereby thrashing 'this' object passed in RCX.  This leads to an AV for the repro case while executing jitted code.\n\nFix is that while allocating LSRA also needs to check that the next use of special putarg_reg is same as the next kill of the fixed register assigned to it. Since first putarg_reg is not marked as special, kill of RCX by GT_SH would lead to spilling of putarg_reg into a tree temp.\n\nFix #1475\n\n[tfs-changeset: 1523584]","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/40cca8c8e8bf5a8bf8da311e8de731691855d3b1"},{"sha":"950e62afe75eade640fa840a87fdcb7120f31a24","author":{"email":"be3f36b6fbce8d4f7a4d47e3a7c547c7aadb94e3@microsoft.com","name":"Lakshmi Priya Sekar"},"message":"Respond to PR feedback.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/950e62afe75eade640fa840a87fdcb7120f31a24"},{"sha":"8f600ec9f9153eac962c20a2d5bf805940462bc7","author":{"email":"c457b3e5195ce3a91c472dc392bcc90fb508bb62@microsoft.com","name":"Jan Vorlicek"},"message":"Fix null reference exception handling in JIT_WriteBarrier\n\nThis change fixes an issue when a null reference exception happens in the first\ninstruction of the JIT_WriteBarrier. There were two problems.\n\nFirst problem was that the native unwinder didn't know that it is unwinding a\nframe where the PC is an address of a failing instruction instead of the next\naddress after a call instruction. So it decremented the PC before looking up the\nunwind info. Unfortunately, that means that if the hardware exception happens\nin the first instruction, the unwind info is not found and the unwinder resorts\nto RBP chain unwinding, which effectively skips one managed frame.\n\nThe second problem was that the FaultingExceptionFrame we create when handling\nthe hardware exception had context pointing to the JIT_WriteBarrier. But that\nbreaks the stack walker. When it arrives at the FaultingExceptionFrame, it\ncalls its ReturnAddress method and expects to get a managed code address.\nHowever, in this case, it was getting the address of the JIT_WriteBarrier instead\nand that made the stack walker to skip to the next explicit frame, effectively\nskipping multiple managed frames that it should have reported.","distinct":false,"url":"https://api.github.com/repos/benpye/coreclr/commits/8f600ec9f9153eac962c20a2d5bf805940462bc7"}]}