{"push_id":644373308,"size":9,"distinct_size":1,"ref":"refs/heads/palthread","head":"0ad15d434a1a37aeb35e43441cb1b310bec026c1","before":"28756016889dcf0f3df90eca1fceeee903e8e98b","commits":[{"sha":"fa416704b3de7c57589284d6f20b59cee4908d83","author":{"email":"fa77123c115913ca9e97c82fc48a0b47e477b7b4@microsoft.com","name":"Mike McLaughlin"},"message":"Implemented hardware exception chaining.\n\nTest CLR hosting under a debugger (lldb). In order to test the debugger modules and coreclr running together in the same process, add the test command \"corerun\" to the lldb plugin that uses the CLR hosting apis to run managed code in the lldb process.\n\nFixed a problem where the dac module was picking up an constructor in the coreclr module instead of using the dac version. This is because the corerun code was dlopen'ing coreclr with RTLD_GLOBAL which exposed all the symbols to the reset of the dynamic modules loaded.  Changing it to RTLD_LOCAL (the default) fixes this problem.\n\nChanged from an ASSERT to an ERROR in the hardware exception handler because ASSERT does an SIGTRAP (DebugBreak) that keeps recursively being hit.\n\nRemoved all signals that installed a fatal_signal_handler especially SIGINT which was interfering with lldb's. The rest of the signals, the default action should be good enough.\n\nChecked if the EE was started in the VM's hardware exception handler just to make sure everything is ready before the managed exception chain is called.\n\nCleanup signal thread masking. Only wait for SIGINT/SIGQUIT explicitly instead of trying to mask all the signals we don't want to wait on.","distinct":false,"url":"https://api.github.com/repos/mikem8361/coreclr/commits/fa416704b3de7c57589284d6f20b59cee4908d83"},{"sha":"fb8b98718c7e92604309c55d5989bf568cc8c73e","author":{"email":"972a13cbbe5e845ecb59dace8e3ece01450d33f4@lander.ca","name":"Rich Lander"},"message":"Update binary distribution instructions","distinct":false,"url":"https://api.github.com/repos/mikem8361/coreclr/commits/fb8b98718c7e92604309c55d5989bf568cc8c73e"},{"sha":"4f69f0a93984795e699a3cfe168f10fe6b77431c","author":{"email":"293b4d95480886f72df8fadcd427f82f74c18be1@microsoft.com","name":"Rich Lander"},"message":"Merge pull request #806 from richlander/rich-getcoreclr\n\nUpdate binary distribution instructions","distinct":false,"url":"https://api.github.com/repos/mikem8361/coreclr/commits/4f69f0a93984795e699a3cfe168f10fe6b77431c"},{"sha":"d8e94fbef54438383223f8afce3a2b89f8f8a8a3","author":{"email":"293b4d95480886f72df8fadcd427f82f74c18be1@microsoft.com","name":"Richard Lander"},"message":"Fix typo","distinct":false,"url":"https://api.github.com/repos/mikem8361/coreclr/commits/d8e94fbef54438383223f8afce3a2b89f8f8a8a3"},{"sha":"82413deb0c7055da784c934101a2e1eed3bfb8ca","author":{"email":"293b4d95480886f72df8fadcd427f82f74c18be1@microsoft.com","name":"Rich Lander"},"message":"Merge pull request #811 from richlander/rich-dnx\n\nFix typo","distinct":false,"url":"https://api.github.com/repos/mikem8361/coreclr/commits/82413deb0c7055da784c934101a2e1eed3bfb8ca"},{"sha":"148ca53afcdf60cfb2b1e52e591822cf82eb60fb","author":{"email":"c457b3e5195ce3a91c472dc392bcc90fb508bb62@microsoft.com","name":"Jan Vorlicek"},"message":"Fix OSX hardware exception handling\n\nThis change fixes a bug in the OSX hardware exception handling. The catch_exception_raise\nfunction in machexceptions.cpp creates a stack frame that allows stack unwinder to\nwalk to the place where the hardware exception happened from the actual exception\nhandling code.\nThe problem was that this method stores the address of the faulting instruction\nPLUS 1 as the return address on the stack. There was a long comment about the\nreasons for doing so, but these reasons are not valid for jitted code that we\nunwind using the windows style unwinder and the \"+1\" breaks the unwinder in\nsome cases.\nIn the case that we've hit, there was an idiv instruction with instruction code\n0xF7 0xFF, followed by instruction code 0x25. The windows style unwinder got\nthe address of the second byte of the instruction code, the 0xFF, which followed\nby the 0x25 is an unconditional indirect jump. So the unwinder decided based on\nthat that it is in the epilogue of the function and returned an unwound context\ncontaining an invalid instruction pointer.\nThe fix is to not to increase the instruction by one in the catch_exception_raise.\nWe don't do that in the Linux exception handling either.\nWe may need to do this fixup at other place for exceptions happening in the debugger\nlibraries where a hardware exception can happen and be handled in our C++ code as well.","distinct":false,"url":"https://api.github.com/repos/mikem8361/coreclr/commits/148ca53afcdf60cfb2b1e52e591822cf82eb60fb"},{"sha":"4b46c486409a9f27c148715cadee4dac1dac0d57","author":{"email":"c457b3e5195ce3a91c472dc392bcc90fb508bb62@microsoft.com","name":"Jan Vorlicek"},"message":"Merge pull request #813 from janvorli/fix-osx-hw-exceptions\n\nFix OSX hardware exception handling","distinct":false,"url":"https://api.github.com/repos/mikem8361/coreclr/commits/4b46c486409a9f27c148715cadee4dac1dac0d57"},{"sha":"6b3adab81e447e3ee68c4b2b713bff493fbfd911","author":{"email":"ae5000fff3f1e1dc00cab1bee3cf3dd6470f3a18@users.noreply.github.com","name":"Mike McLaughlin"},"message":"Merge pull request #807 from mikem8361/testcoreclrindebugger\n\nImplemented hardware exception chaining.","distinct":false,"url":"https://api.github.com/repos/mikem8361/coreclr/commits/6b3adab81e447e3ee68c4b2b713bff493fbfd911"},{"sha":"0ad15d434a1a37aeb35e43441cb1b310bec026c1","author":{"email":"fa77123c115913ca9e97c82fc48a0b47e477b7b4@microsoft.com","name":"Mike McLaughlin"},"message":"Create CPalThread object on the fly in InternalGetCurrentThread. SIGUSR1/SIGUSR2 are needed by the PAL thread\nsuspend/resume logic. Enable them for PAL_InitializeDLL.","distinct":true,"url":"https://api.github.com/repos/mikem8361/coreclr/commits/0ad15d434a1a37aeb35e43441cb1b310bec026c1"}]}