Hi, I'd like to submit a patch to match the clang patch on the front end. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html The front end doesn't need this patch to work but it's still important. This is mostly based on work done by kai from redstar.de Could I get some feedback on this? I'm not sure if the emitting of the register names will effect msvc. Many Thanks Martell Malone -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140415/70489003/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-win64-exceptions.patch Type: application/octet-stream Size: 16693 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140415/70489003/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-emit-reg-names.patch Type: application/octet-stream Size: 1754 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140415/70489003/attachment-0001.obj>
Hi, if (is64Bit && T.getOS() == Triple::MinGW32 && T.getEnvironment() && Triple::GNU) should be if (is64Bit && Triple.isWindowsGNUEnvironment()) Yaron 2014-04-15 21:43 GMT+03:00 Martell Malone <martellmalone at gmail.com>:> Hi, > > I'd like to submit a patch to match the clang patch on the front end. > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html > > The front end doesn't need this patch to work but it's still important. > This is mostly based on work done by kai from redstar.de > > Could I get some feedback on this? > I'm not sure if the emitting of the register names will effect msvc. > > Many Thanks > > Martell Malone > > _______________________________________________ > 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/20140415/d98b5ec6/attachment.html>
Updated patch. I've reordered seh patch to have includes in the correct location Was a very sloppy edit before On Tue, Apr 15, 2014 at 7:43 PM, Martell Malone <martellmalone at gmail.com>wrote:> Hi, > > I'd like to submit a patch to match the clang patch on the front end. > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html > > The front end doesn't need this patch to work but it's still important. > This is mostly based on work done by kai from redstar.de > > Could I get some feedback on this? > I'm not sure if the emitting of the register names will effect msvc. > > Many Thanks > > Martell Malone >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140415/a925078f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-win64-exceptions.patch Type: application/octet-stream Size: 16958 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140415/a925078f/attachment.obj>
Hi yaron, Good spot :) missed that in my conversion. Updated patch attached On Tue, Apr 15, 2014 at 9:45 PM, Martell Malone <martellmalone at gmail.com>wrote:> Updated patch. > > I've reordered seh patch to have includes in the correct location > Was a very sloppy edit before > > > > On Tue, Apr 15, 2014 at 7:43 PM, Martell Malone <martellmalone at gmail.com>wrote: > >> Hi, >> >> I'd like to submit a patch to match the clang patch on the front end. >> >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html >> >> The front end doesn't need this patch to work but it's still important. >> This is mostly based on work done by kai from redstar.de >> >> Could I get some feedback on this? >> I'm not sure if the emitting of the register names will effect msvc. >> >> Many Thanks >> >> Martell Malone >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140415/98ef47c9/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-win64-exceptions.patch Type: application/octet-stream Size: 16925 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140415/98ef47c9/attachment.obj>
Hi, I am curious - how does clang deal with epilogue-less functions that result from _Raise_Exception being marked 'noreturn'? I've also been playing with Kai's patch, and discovered that this tends to greatly confuse Windows stack unwinder in cases when noreturn call is at the end of a function, so execution appears to flow directly into the prologue of the next function. It looks like MSVC solves this problem by inserting 'int 3' after calls to noreturns. This is actually the prime motivation for me wanting to emit code for 'unreachable'<http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/072145.html>... Vadim On Tue, Apr 15, 2014 at 11:43 AM, Martell Malone <martellmalone at gmail.com>wrote:> Hi, > > I'd like to submit a patch to match the clang patch on the front end. > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html > > The front end doesn't need this patch to work but it's still important. > This is mostly based on work done by kai from redstar.de > > Could I get some feedback on this? > I'm not sure if the emitting of the register names will effect msvc. > > Many Thanks > > Martell Malone > > _______________________________________________ > 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/20140415/2f93380d/attachment.html>
Hi, I am curious - how does clang deal with epilogue-less functions that result from _Raise_Exception being marked 'noreturn'? I've also been playing with Kai's patch, and discovered that this tends to greatly confuse Windows stack unwinder in cases when noreturn call is at the end of a function, so execution appears to flow directly into the prologue of the next function. It looks like MSVC solves this problem by inserting 'int 3' after calls to noreturns. This is actually the prime motivation for me wanting to emit code for 'unreachable'<http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/072145.html>... Vadim On Tue, Apr 15, 2014 at 11:43 AM, Martell Malone <martellmalone at gmail.com>wrote:> Hi, > > I'd like to submit a patch to match the clang patch on the front end. > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html > > The front end doesn't need this patch to work but it's still important. > This is mostly based on work done by kai from redstar.de > > Could I get some feedback on this? > I'm not sure if the emitting of the register names will effect msvc. > > Many Thanks > > Martell Malone > > _______________________________________________ > 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/20140415/a0e8b60b/attachment.html>
On 15.04.2014 20:43, Martell Malone wrote:> Could I get some feedback on this? > I'm not sure if the emitting of the register names will effect msvc.Emitting the register names LGTM (in fact GAS doesn't seem to be able to parse this anyway). Since this is just GAS assembly, this does not affect MSVC. Some tests would be nice, if possible. Unwind emission still suffers from the same problems that the old code did. It doesn't handle realigned stacks, and as I summarized in PR16779, I believe it's not necessary to change the prologue emission for Win64. Currently ilist_node::getPrevNode of MachineInstr is unusable because it segfaults on the first node in a list. I raised this issue before on llvm-dev and proposed a patch but nobody cared, so you have to do something like this: static const MachineInstr *getPrevNode(const MachineInstr *MI) { if (&*MI->getParent()->instr_begin() == MI) return nullptr; return MI->getPrevNode(); } Some small nits:> + if (MI->getOperand(1).getImm() != 1 || MI->getOperand(2).getImm() != 0 || > + MI->getOperand(4).getImm() != 0)Spacing. Also, a comment clarifying that scale/index/segment must be unused might be helpful here. + if (MI->getNextNode()) { + const MachineInstr *MI2 = MI->getNextNode(); + if (!(MI2->getFlag(MachineInstr::FrameSetup) || + (MI2->isCFIInstruction() && MI2->getNextNode() && + MI2->getNextNode()->getFlag(MachineInstr::FrameSetup)))) { + OutStreamer.EmitWin64EHEndProlog(); + } + } I'd simplify this and just skip over all CFI instructions. If there's still a node left, and it lacks the FrameSetup flag, end the prolog.> +; WIN64: callq {{__chkstk|___chkstk_ms}}This check should really differentiate between MSVC and Mingw. You can add additional FileCheck prefixes so the rest does not have to be duplicated. Overall this needs more tests covering __chkstk, alloca, manual over-alignment and various combinations. On 15.04.2014 23:44, Vadim Chugunov wrote:> I am curious - how does clang deal with epilogue-less functions that result > from _Raise_Exception being marked 'noreturn'?AFAIK it doesn't emit anything.> I've also been playing with Kai's patch, and discovered that this tends to > greatly confuse Windows stack unwinder in cases when noreturn call is at > the end of a function, so execution appears to flow directly into the > prologue of the next function. > It looks like MSVC solves this problem by inserting 'int 3' after calls to > noreturns.The unwinder starts scanning forward looking for an optional add or lea, then zero or more register pops, followed by a ret or a few simple jmp variants. So you can insert anything except these. Though int3 would probably make the most sense. -Nico
Hi, On 15.04.2014 23:44, Vadim Chugunov wrote:> Hi, > I am curious - how does clang deal with epilogue-less functions that > result from _Raise_Exception being marked 'noreturn'? > I've also been playing with Kai's patch, and discovered that this tends > to greatly confuse Windows stack unwinder in cases when noreturn call is > at the end of a function, so execution appears to flow directly into the > prologue of the next function.Yes, that's true. The patch has a problem if the epilogue is dead code and eliminated.> It looks like MSVC solves this problem by inserting 'int 3' after calls > to noreturns. This is actually the prime motivation for me wanting to > emit code for 'unreachable' > <http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/072145.html> ... > > VadimYaron also pointed out that int main() { throw 1; } generates two .seh_endprologue instructions. I still did not fix this bug. Regards, Kai> > > On Tue, Apr 15, 2014 at 11:43 AM, Martell Malone > <martellmalone at gmail.com <mailto:martellmalone at gmail.com>> wrote: > > Hi, > > I'd like to submit a patch to match the clang patch on the front end. > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html > > The front end doesn't need this patch to work but it's still important. > This is mostly based on work done by kai from redstar.de > <http://redstar.de> > > Could I get some feedback on this? > I'm not sure if the emitting of the register names will effect msvc. > > Many Thanks > > Martell Malone > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Tue, Apr 15, 2014 at 11:43 AM, Martell Malone <martellmalone at gmail.com>wrote:> This is mostly based on work done by kai from redstar.de >Martell, you really cannot post patches for review or otherwise contribute them to LLVM unless you authored the patch. If Kai authored the patch, then Kai needs to contirbute it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140418/246efd3e/attachment.html>
Hi Chandler, Kai contributed the WIN64 SEH patch some time ago on llvm-commits: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131118/196105.html it was never completed. Kai also responded in this thread. I opened a phabricator for the patch http://reviews.llvm.org/D3418 Yaron 2014-04-18 12:31 GMT+03:00 Chandler Carruth <chandlerc at google.com>:> > On Tue, Apr 15, 2014 at 11:43 AM, Martell Malone <martellmalone at gmail.com>wrote: > >> This is mostly based on work done by kai from redstar.de >> > > Martell, you really cannot post patches for review or otherwise contribute > them to LLVM unless you authored the patch. If Kai authored the patch, then > Kai needs to contirbute it. > > _______________________________________________ > 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/20140418/7ffaf8e1/attachment.html>
Hi Chandler & all others, yes, I contribute the patch here. :-) Regards, Kai On 18.04.2014 11:31, Chandler Carruth wrote:> > On Tue, Apr 15, 2014 at 11:43 AM, Martell Malone > <martellmalone at gmail.com <mailto:martellmalone at gmail.com>> wrote: > > This is mostly based on work done by kai from redstar.de > <http://redstar.de> > > > Martell, you really cannot post patches for review or otherwise > contribute them to LLVM unless you authored the patch. If Kai authored > the patch, then Kai needs to contirbute it. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Apparently Analagous Threads
- [LLVMdev] [PATCH] Seh exceptions on Win64
- [RFC] Strategies for Bootstrapping Compiler-RT builtins
- RFC: A new llvm-dlltool driver and llvm-lib driver improvements
- [LLVMdev] [LLD] support for dlltool generated libs in COFF/PECOFF
- RFC: A new llvm-dlltool driver and llvm-lib driver improvements