Ok, I've isolated the recent additions that cause the issue and supplied a patch which is NOT meant to be applied, but instead solely exists for identification purposes for those who know what they are doing. :-) The patch is offset from HEAD. The patch is a hack which removes use of the MCSymbol::isDefined(...) method, as its use happens to break in the exception JIT context; both in MachineModuleInfo.:: TidyLandingPads(...) and in JITDwarfException:: EmitFrameMoves(...). In this context these symbols are not defined but rather are temporaries. Beyond this I don't understand what the correct replacement is, or whether or not the use of MCSymbol::isDefined(...) can be dropped from TidyLandingPads(...) since there are probably other dependencies. In 2.7 JITDwarfException:: EmitFrameMoves(...) used to check if the associated label id was deleted or folded into another. I guess the intent may now be to have this happen automatically to MCSymbol instances? I understand that trunk is being heavily thrashed in this area. Do you want me to turn ExceptionDemo into a related unit test case even though it only works on x86/x86_64 on UNIX systems, and requires exceptions to be turned on? Garrison On Mar 18, 2010, at 14:41, Garrison Venn wrote:> Forgot to add platform with issue: OS X 10.6.2. I have not tested elsewhere. > > Garrison > > On Mar 18, 2010, at 14:20, Garrison Venn wrote: > >> Hi Chris, >> >> The MCSymbol r98459 patch of llvm seems to have broken the ExceptionDemo example. As the example is dying in the >> associated personality's first unwind search phase, which happens to have no language specific context, and is returning >> a _URC_CONTINUE_UNWIND, I believe the issue is generic and not specific to the example. However I'm not sure why then >> this wasn't seen in one of the test cases. Anyway just wanted to give a heads up as I'm studying this, just in case the problem >> is obvious to you. One way to reproduce this in trunk from root is to: >> >> 1) set environment var BUILD_EXAMPLES 1 >> >> 2) svn switch -r 98458 http://llvm.org/svn/llvm-project/llvm/trunk >> 3) make >> 4) Debug/examples/ExceptionDemo 2 >> 5) example will complete successfully >> >> 6) svn switch -r 98459 http://llvm.org/svn/llvm-project/llvm/trunk >> 7) make >> 8) Debug/examples/ExceptionDemo 2 >> 9) example will segv >> >> Sorry I'm late identifying this. I'll keep on trying to isolate it further, though I'm guessing that the sensitivity is in JITDwarfEmitter. >> >> Garrison >> >> PS: Patch ref: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097798.html >-------------- next part -------------- A non-text attachment was scrubbed... Name: NewMCAdds_ProbExceptionHack.patch Type: application/octet-stream Size: 2822 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100322/882a730c/attachment.obj>
Hi Garrison, Does r101453 fix this? -Chris On Mar 22, 2010, at 12:35 PM, Garrison Venn wrote:> Ok, I've isolated the recent additions that cause the issue and supplied a patch which is NOT meant > to be applied, but instead solely exists for identification purposes for those who know what they are doing. :-) > The patch is offset from HEAD. > > The patch is a hack which removes use of the MCSymbol::isDefined(...) method, as its use happens to break > in the exception JIT context; both in MachineModuleInfo.:: TidyLandingPads(...) and in JITDwarfException:: > EmitFrameMoves(...). In this context these symbols are not defined but rather are temporaries. Beyond this > I don't understand what the correct replacement is, or whether or not the use of MCSymbol::isDefined(...) can be > dropped from TidyLandingPads(...) since there are probably other dependencies. In 2.7 JITDwarfException:: > EmitFrameMoves(...) used to check if the associated label id was deleted or folded into another. I guess the > intent may now be to have this happen automatically to MCSymbol instances? > > I understand that trunk is being heavily thrashed in this area. Do you want me to turn ExceptionDemo into a related unit > test case even though it only works on x86/x86_64 on UNIX systems, and requires exceptions to be turned on? > > Garrison > > On Mar 18, 2010, at 14:41, Garrison Venn wrote: > >> Forgot to add platform with issue: OS X 10.6.2. I have not tested elsewhere. >> >> Garrison >> >> On Mar 18, 2010, at 14:20, Garrison Venn wrote: >> >>> Hi Chris, >>> >>> The MCSymbol r98459 patch of llvm seems to have broken the ExceptionDemo example. As the example is dying in the >>> associated personality's first unwind search phase, which happens to have no language specific context, and is returning >>> a _URC_CONTINUE_UNWIND, I believe the issue is generic and not specific to the example. However I'm not sure why then >>> this wasn't seen in one of the test cases. Anyway just wanted to give a heads up as I'm studying this, just in case the problem >>> is obvious to you. One way to reproduce this in trunk from root is to: >>> >>> 1) set environment var BUILD_EXAMPLES 1 >>> >>> 2) svn switch -r 98458 http://llvm.org/svn/llvm-project/llvm/trunk >>> 3) make >>> 4) Debug/examples/ExceptionDemo 2 >>> 5) example will complete successfully >>> >>> 6) svn switch -r 98459 http://llvm.org/svn/llvm-project/llvm/trunk >>> 7) make >>> 8) Debug/examples/ExceptionDemo 2 >>> 9) example will segv >>> >>> Sorry I'm late identifying this. I'll keep on trying to isolate it further, though I'm guessing that the sensitivity is in JITDwarfEmitter. >>> >>> Garrison >>> >>> PS: Patch ref: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097798.html >> > > <NewMCAdds_ProbExceptionHack.patch>
By itself no, but adding in Bill's 101686 mod to JITDwarfEmitter does. Thanks guys, I had a feeling my isTemporary() hack was too overbearing. Does anybody have an objection to turing a version of the ExceptionDemo into a unit test? The unit test would require exceptions to be turned on for it, and it would be somewhat large. I'll interpret a no response as a no (as in don't do this). Thanks again Garrison On Apr 16, 2010, at 14:23, Chris Lattner wrote:> Hi Garrison, > > Does r101453 fix this? > > -Chris > > On Mar 22, 2010, at 12:35 PM, Garrison Venn wrote: > >> Ok, I've isolated the recent additions that cause the issue and supplied a patch which is NOT meant >> to be applied, but instead solely exists for identification purposes for those who know what they are doing. :-) >> The patch is offset from HEAD. >> >> The patch is a hack which removes use of the MCSymbol::isDefined(...) method, as its use happens to break >> in the exception JIT context; both in MachineModuleInfo.:: TidyLandingPads(...) and in JITDwarfException:: >> EmitFrameMoves(...). In this context these symbols are not defined but rather are temporaries. Beyond this >> I don't understand what the correct replacement is, or whether or not the use of MCSymbol::isDefined(...) can be >> dropped from TidyLandingPads(...) since there are probably other dependencies. In 2.7 JITDwarfException:: >> EmitFrameMoves(...) used to check if the associated label id was deleted or folded into another. I guess the >> intent may now be to have this happen automatically to MCSymbol instances? >> >> I understand that trunk is being heavily thrashed in this area. Do you want me to turn ExceptionDemo into a related unit >> test case even though it only works on x86/x86_64 on UNIX systems, and requires exceptions to be turned on? >> >> Garrison >> >> On Mar 18, 2010, at 14:41, Garrison Venn wrote: >> >>> Forgot to add platform with issue: OS X 10.6.2. I have not tested elsewhere. >>> >>> Garrison >>> >>> On Mar 18, 2010, at 14:20, Garrison Venn wrote: >>> >>>> Hi Chris, >>>> >>>> The MCSymbol r98459 patch of llvm seems to have broken the ExceptionDemo example. As the example is dying in the >>>> associated personality's first unwind search phase, which happens to have no language specific context, and is returning >>>> a _URC_CONTINUE_UNWIND, I believe the issue is generic and not specific to the example. However I'm not sure why then >>>> this wasn't seen in one of the test cases. Anyway just wanted to give a heads up as I'm studying this, just in case the problem >>>> is obvious to you. One way to reproduce this in trunk from root is to: >>>> >>>> 1) set environment var BUILD_EXAMPLES 1 >>>> >>>> 2) svn switch -r 98458 http://llvm.org/svn/llvm-project/llvm/trunk >>>> 3) make >>>> 4) Debug/examples/ExceptionDemo 2 >>>> 5) example will complete successfully >>>> >>>> 6) svn switch -r 98459 http://llvm.org/svn/llvm-project/llvm/trunk >>>> 7) make >>>> 8) Debug/examples/ExceptionDemo 2 >>>> 9) example will segv >>>> >>>> Sorry I'm late identifying this. I'll keep on trying to isolate it further, though I'm guessing that the sensitivity is in JITDwarfEmitter. >>>> >>>> Garrison >>>> >>>> PS: Patch ref: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097798.html >>> >> >> <NewMCAdds_ProbExceptionHack.patch> >