[LLVMdev] alloca on Win32

Scott Graham scott.llvm at h4ck3r.net
Sun Jun 24 16:37:45 PDT 2007


Hi

Thanks for the help Jake and Anton.

Attached is a patch for DynamicLibrary.inc to fix alloca resolving. It uses
the function that _alloca compiles to when it's compiled by VS. (==
_alloca_probe == _chkstk). I tried this in 2003, but I haven't grabbed the
post-2.0 from CVS to try with 2005. Looking at the code for 2005, it looks
as if it will work fine.

scott

On 6/24/07, Jake <jake at jakeonthenet.com> wrote:
>
> 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
> >
> >
>
> _______________________________________________
> 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/ddfa6305/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lli-alloca-msvc.patch
Type: application/octet-stream
Size: 993 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070624/ddfa6305/attachment.obj>


More information about the llvm-dev mailing list