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...
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…).
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.
Well, in general, it's dangerous, because you should probe the stack on
windows, if you'll allocate more than 4k. This is needed to let guard
pages be allocated in proper order.
So, you can see random crashes here and there now For example: try to
allocate big array (>4k of size) and touch its last element (this should
be in the second page) without touching somewhere in the beginning (to
be in the first page). It'll crash fast.
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).
As I've mentioned, it's not mingw-special stuff, it's windows-special
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...).
It's in lib/System/Win32/DynamicLibrary.inc
I'd suggest you to check, whether vcpp stack probing routine and _alloca
has the same signature. If yes - we can easily fix the code emission.
Otherwise we'll need extra information about chkstk.
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.
),