Hi, I've been looking at all of the uses of the 'unwind' instruction, and ShadowStackGC.cpp is the last pass which actually creates 'unwind' instructions. The thing is, this pass seems to be dead. It hasn't been updated in any meaningful way since ~79000. Should this pass go the way of the dodo? -bw -------------- next part -------------- A non-text attachment was scrubbed... Name: no-sgc.diff Type: application/octet-stream Size: 18698 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110821/c50965cf/attachment.obj> -------------- next part --------------
Hi Bill,> I've been looking at all of the uses of the 'unwind' instruction, and ShadowStackGC.cpp is the last pass which actually creates 'unwind' instructions. The thing is, this pass seems to be dead. It hasn't been updated in any meaningful way since ~79000. > > Should this pass go the way of the dodo?no idea, but it would be nice if there was a simple way to run some cleanup code then keep unwinding when an exception is unwind. I guess the problem is what personality function to use? It could scan the function, and if it sees an existing landing pad, just reuse that personality function, and otherwise just use the C personality function in the cleanup landing pad it needs to create. It would be neat if a landing pad instruction didn't need a personality function if it only wants to run a cleanup, and have everything be taken care of automagically, but I guess that can be done in some happy future time when the exception handling world has calmed down again :) Ciao, Duncan.
Hi Bill, I don't think it's dead code, per se -- AFAIK there are still clients of LLVM which use the shadow stack as part of their garbage collection implementation. HLVM is probably the most visible such project. My own project now has its own GC plugin to emit stack maps, rather than relying on the shadow stack. But for what it's worth, I found the shadow stack to be a useful stepping stone towards a "real" GC implementation when I first started out with LLVM's garbage collector infrastructure. -- Ben On Sun, Aug 21, 2011 at 5:17 AM, Bill Wendling <wendling at apple.com> wrote:> Hi, > > I've been looking at all of the uses of the 'unwind' instruction, and > ShadowStackGC.cpp is the last pass which actually creates 'unwind' > instructions. The thing is, this pass seems to be dead. It hasn't been > updated in any meaningful way since ~79000. > > Should this pass go the way of the dodo? > > -bw > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110823/63b1de76/attachment.html>
Okay, then I'll try to work around the use of the "unwind" instruction. :-) -bw On Aug 23, 2011, at 7:51 AM, Ben Karel wrote:> Hi Bill, > > I don't think it's dead code, per se -- AFAIK there are still clients of LLVM which use the shadow stack as part of their garbage collection implementation. HLVM is probably the most visible such project. > > My own project now has its own GC plugin to emit stack maps, rather than relying on the shadow stack. But for what it's worth, I found the shadow stack to be a useful stepping stone towards a "real" GC implementation when I first started out with LLVM's garbage collector infrastructure. > > -- Ben > > On Sun, Aug 21, 2011 at 5:17 AM, Bill Wendling <wendling at apple.com> wrote: > Hi, > > I've been looking at all of the uses of the 'unwind' instruction, and ShadowStackGC.cpp is the last pass which actually creates 'unwind' instructions. The thing is, this pass seems to be dead. It hasn't been updated in any meaningful way since ~79000. > > Should this pass go the way of the dodo? > > -bw > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
Assuming you’re referring to my HLVM project, it actually uses its own shadow stack based upon Henderson’s “Accurate Garbage Collection in an uncooperative environment”. I kept it completely separate from LLVM’s GC infrastructure because that was highly experimental at the time… Cheers, Jon. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Ben Karel Sent: 23 August 2011 15:51 To: Bill Wendling Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] ShadowStackGC.cpp - More Dead Code? Hi Bill, I don't think it's dead code, per se -- AFAIK there are still clients of LLVM which use the shadow stack as part of their garbage collection implementation. HLVM is probably the most visible such project. My own project now has its own GC plugin to emit stack maps, rather than relying on the shadow stack. But for what it's worth, I found the shadow stack to be a useful stepping stone towards a "real" GC implementation when I first started out with LLVM's garbage collector infrastructure. -- Ben On Sun, Aug 21, 2011 at 5:17 AM, Bill Wendling <wendling at apple.com> wrote: Hi, I've been looking at all of the uses of the 'unwind' instruction, and ShadowStackGC.cpp is the last pass which actually creates 'unwind' instructions. The thing is, this pass seems to be dead. It hasn't been updated in any meaningful way since ~79000. Should this pass go the way of the dodo? -bw _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111202/c647e36f/attachment.html>