Hello, Scott.> Checking the assembly from llc, the first alloca call is to allocate > local vars in _main. Is this just the state of the code at 2.0 when > built with vs.net, or is there something that I've managed to > mis-build locally?_alloca is used to probe the stack, if you asks for locals of size more that 4k. This is pretty ugly, but the names of this functions differs for mingw32 variant (_alloca) and something like chkstk (vcpp). For mingw32 it's exported in libgcc, dunno about vcpp (probably from some runtime libraries). Since there is no dynamic linking on windows, there is special hook to resolve _alloca call at runtime. Surely, this won't be applicable for lli built by vcpp. Probably, you'll have either to switch to mingw32-built lli or resolve _alloca/chkstk problem somehow (adding hooks, special lowering code, etc). In fact, I don't know, whether _alloca and chkstk has compartible prototypes. If yes, you might probably just change the hook in lli (don't forget to send patch! :) ), if no - you'll have to change lowering code... -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
Hi Thanks for the info, it led to the source of the error I was having. I was using llvm-gcc binaries (built with mingw I guess) to compile a .c file that is my language runtime, llvm-link'ing that with my frontend's .ll, and using an vcpp-built lli to run the resulting bytecode. This caused the special case in X86RegisterInfo::emitPrologue for "main" to try to align the stack using _alloca which caused the problem, because it felt that target was CygMing. Hacking the output of llvc-gcc from target triple="mingw32" to "win32" makes it "work". Is that generally dangerous, or should it be OK? I suppose I'll have to battle with msys/bison/m4 again, but they beat me soundly last time I tried to build mingw-lli. I tried to fix the alloca resolution, as it does appear the same thing will happen once there's > 4k on the stack as you mentioned (mingw hacking or no). I wasn't able to understand where lli was doing the hooking you describe though. Once I have some larger functions, I'll dig in more deeply (or if someone points me at it...). Thanks for the help, scott On 6/24/07, Anton Korobeynikov <asl at math.spbu.ru> wrote:> > Hello, Scott. > > > Checking the assembly from llc, the first alloca call is to allocate > > local vars in _main. Is this just the state of the code at 2.0 when > > built with vs.net, or is there something that I've managed to > > mis-build locally? > > _alloca is used to probe the stack, if you asks for locals of size more > that 4k. This is pretty ugly, but the names of this functions differs > for mingw32 variant (_alloca) and something like chkstk (vcpp). For > mingw32 it's exported in libgcc, dunno about vcpp (probably from some > runtime libraries). > > Since there is no dynamic linking on windows, there is special hook to > resolve _alloca call at runtime. Surely, this won't be applicable for > lli built by vcpp. Probably, you'll have either to switch to > mingw32-built lli or resolve _alloca/chkstk problem somehow (adding > hooks, special lowering code, etc). In fact, I don't know, whether > _alloca and chkstk has compartible prototypes. If yes, you might > probably just change the hook in lli (don't forget to send patch! :) ), > if no - you'll have to change lowering code... > > -- > With best regards, Anton Korobeynikov. > > Faculty of Mathematics & Mechanics, Saint Petersburg State University. > > > _______________________________________________ > 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/20070624/91fbfe75/attachment.html>
The alloca hook is in lib\System\Win32\DynamicLibrary.inc all the way at the bottom. You'll see a __MING32__ #ifdef around the definition. You just have to implement those methods and it'll work just fine. Jake On 6/24/07, Scott Graham <scott.llvm at h4ck3r.net> wrote:> > Hi > > Thanks for the info, it led to the source of the error I was having. > > I was using llvm-gcc binaries (built with mingw I guess) to compile a .c > file that is my language runtime, llvm-link'ing that with my frontend's .ll, > and using an vcpp-built lli to run the resulting bytecode. This caused the > special case in X86RegisterInfo::emitPrologue for "main" to try to align the > stack using _alloca which caused the problem, because it felt that target > was CygMing. Hacking the output of llvc-gcc from target triple="mingw32" to > "win32" makes it "work". Is that generally dangerous, or should it be OK? I > suppose I'll have to battle with msys/bison/m4 again, but they beat me > soundly last time I tried to build mingw-lli. > > I tried to fix the alloca resolution, as it does appear the same thing > will happen once there's > 4k on the stack as you mentioned (mingw hacking > or no). I wasn't able to understand where lli was doing the hooking you > describe though. Once I have some larger functions, I'll dig in more deeply > (or if someone points me at it...). > > Thanks for the help, > scott > > > On 6/24/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > > > > Hello, Scott. > > > > > Checking the assembly from llc, the first alloca call is to allocate > > > local vars in _main. Is this just the state of the code at 2.0 when > > > built with vs.net , or is there something that I've managed to > > > mis-build locally? > > > > _alloca is used to probe the stack, if you asks for locals of size more > > that 4k. This is pretty ugly, but the names of this functions differs > > for mingw32 variant (_alloca) and something like chkstk (vcpp). For > > mingw32 it's exported in libgcc, dunno about vcpp (probably from some > > runtime libraries). > > > > Since there is no dynamic linking on windows, there is special hook to > > resolve _alloca call at runtime. Surely, this won't be applicable for > > lli built by vcpp. Probably, you'll have either to switch to > > mingw32-built lli or resolve _alloca/chkstk problem somehow (adding > > hooks, special lowering code, etc). In fact, I don't know, whether > > _alloca and chkstk has compartible prototypes. If yes, you might > > probably just change the hook in lli (don't forget to send patch! :) ), > > if no - you'll have to change lowering code... > > > > -- > > With best regards, Anton Korobeynikov. > > > > Faculty of Mathematics & Mechanics, Saint Petersburg State University. > > > > > > _______________________________________________ > > LLVM Developers mailing list > > 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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070624/5b03d8ca/attachment.html>
Hello, Scott.> Thanks for the help Jake and Anton. > Attached is a patch for DynamicLibrary.inc to fix alloca resolving.Thanks! I've slightly modified it not to break the things and have just commited. Could you please verify, that everything is ok? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
On 6/25/07, Anton Korobeynikov <asl at math.spbu.ru> wrote:> > Attached is a patch for DynamicLibrary.inc to fix alloca resolving. > Thanks! I've slightly modified it not to break the things and have just > commited. Could you please verify, that everything is ok?Sorry, I did quite a bad job on picking pp defines. Anyway, yes, your fixed up version works fine for me. scott -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070625/d6f664c4/attachment.html>
Hello, Scott> Sorry, I did quite a bad job on picking pp defines.No problem> Anyway, yes, your fixed up version works fine for me.Ok. Thanks for patch! PS: Usually it's better to post patches to llvm-commits list -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.