thr3ads.net - llvm dev - [LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen? [Oct 2013]

If this information is useful, please help other people find it:
Share via:

Yaron Keren

2013-Oct-22 17:16 UTC

[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?

OS is Windows 7 64 bit OS, compiler is 32 bit Visual C++ 2012 with 32 bit.
The target which is i686-pc-mingw32-elf so I can use the ELF dynamic
loader.
Code model, relocation model and and memory manager are whatever default
for this - did not modify.

The Module comes from clang. The source is 1000 or more lines repeating C++
code in one big function:

  A+1;
  A*B.t();

where A and B are matrices from Armadillo http://arma.sourceforge.net/.
This a stress and performance test due to the large number of EH and
temporary objects created.

I am using the Engine Builder and MCJIT unmodified (except the
multi-modules patches which are not relevant as there is only one module)
like this:

  OwningPtr<llvm::ExecutionEngine> EE(llvm::EngineBuilder(M)
                                          .setErrorStr(&Error)
                                          .setUseMCJIT(true)
                                          .create());

to run the function either

  llvm::Function *F = M->getFunction(Name);
  void *FN = EE->getPointerToFunction(F);
or
  uint64_t FN = EE->getFunctionAddress(Name);

followed by

 ((void (*)())FN)();
or
  EE->runFunction(F, std::vector<llvm::GenericValue>());

all work the same with smaller about 1000 lines of the above code module
and crash the same with more code. The call stack is unhelpful Visual C++
says: Frames below may be incorrect and/or missing which indicates a real
problem with it. I have tried to provide less stack space (default is 10M)
for the compiled program without any change.

Yaron



2013/10/22 Kaylor, Andrew <andrew.kaylor at intel.com>
>  I’m not aware of such a limitation.****
>
> ** **
>
> What architecture, code model and relocation model are you using?  Are you
> using the SectionMemoryManager?****
>
> ** **
>
> -Andy****
>
> ** **
>
> *From:* Yaron Keren [mailto:yaron.keren at gmail.com]
> *Sent:* Tuesday, October 22, 2013 8:12 AM
> *To:* <llvmdev at cs.uiuc.edu>; Kaylor, Andrew
> *Subject:* Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?***
> *
>
> ** **
>
> I'm running in MCJIT a module generated from one C++ function. Every
line
> of the source function uses C++ classes and may throw an exception. As long
> as there are less than (about) 1000 lines, everything works. With more
> lines the compiled code crashes when running it, with no sensible stack
> trace.****
>
> ** **
>
> Is there any kind of hard-coded size limitation in MCJIT / ELF Dynamic
> Linker / ELF codegen / number of EH states in a function ? ****
>
> ** **
>
> I did browse the code but could not find anything obvious. ****
>
> ** **
>
> Yaron****
>
> ** **
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131022/f4d24c2d/attachment.html>

Kaylor, Andrew

2013-Oct-22 17:41 UTC

head link

[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?

I would guess that it's crashing somewhere in the generated code.  On
Windows we don't have a way to get call stacks to the generated code (though
if you want to try it on Linux, that should work).  You can probably look at the
address where the crash is occurring and verify that it is in the generated
code.

There are a couple of things I would look for.

First, I'd take a look at the SectionMemoryManager allocation handling.  The
fact that the problem is code size dependent strongly points in this direction. 
It may be that SectionMemoryManager does something wrong when it hits a page
boundary or something.

Second, I'd look at the relocation processing.  If it is generating any
stubs, that would be a potential problem spot, but it shouldn't be
generating any stubs.  So the obvious thing to look at is whether any of the
relocations are writing to the spot where the crash occurs.

-Andy


From: Yaron Keren [mailto:yaron.keren at gmail.com]
Sent: Tuesday, October 22, 2013 10:17 AM
To: Kaylor, Andrew
Cc: <llvmdev at cs.uiuc.edu>
Subject: Re: Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?

OS is Windows 7 64 bit OS, compiler is 32 bit Visual C++ 2012 with 32 bit.
The target which is i686-pc-mingw32-elf so I can use the ELF dynamic loader.
Code model, relocation model and and memory manager are whatever default for
this - did not modify.

The Module comes from clang. The source is 1000 or more lines repeating C++ code
in one big function:

  A+1;
  A*B.t();

where A and B are matrices from Armadillo http://arma.sourceforge.net/. This a
stress and performance test due to the large number of EH and temporary objects
created.

I am using the Engine Builder and MCJIT unmodified (except the multi-modules
patches which are not relevant as there is only one module) like this:

  OwningPtr<llvm::ExecutionEngine> EE(llvm::EngineBuilder(M)
                                          .setErrorStr(&Error)
                                          .setUseMCJIT(true)
                                          .create());

to run the function either

  llvm::Function *F = M->getFunction(Name);
  void *FN = EE->getPointerToFunction(F);
or
  uint64_t FN = EE->getFunctionAddress(Name);

followed by

 ((void (*)())FN)();
or
  EE->runFunction(F, std::vector<llvm::GenericValue>());

all work the same with smaller about 1000 lines of the above code module and
crash the same with more code. The call stack is unhelpful Visual C++ says:
Frames below may be incorrect and/or missing which indicates a real problem with
it. I have tried to provide less stack space (default is 10M) for the compiled
program without any change.

Yaron


2013/10/22 Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor
at intel.com>>
I'm not aware of such a limitation.

What architecture, code model and relocation model are you using?  Are you using
the SectionMemoryManager?

-Andy

From: Yaron Keren [mailto:yaron.keren at gmail.com<mailto:yaron.keren at
gmail.com>]
Sent: Tuesday, October 22, 2013 8:12 AM
To: <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>; Kaylor,
Andrew
Subject: Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?

I'm running in MCJIT a module generated from one C++ function. Every line of
the source function uses C++ classes and may throw an exception. As long as
there are less than (about) 1000 lines, everything works. With more lines the
compiled code crashes when running it, with no sensible stack trace.

Is there any kind of hard-coded size limitation in MCJIT / ELF Dynamic Linker /
ELF codegen / number of EH states in a function ?

I did browse the code but could not find anything obvious.

Yaron


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131022/733dd447/attachment.html>

Yaron Keren

2013-Oct-22 20:40 UTC

head link

[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?

Hi,

Thanks for your ideas.

Memory allocation already exceeds 2x64K in the "working" case so
it's not
the condition of allocating more than 64K. To be sure I had modified
SectionMemoryManager::allocateSection to allocate four time the required
memory but it did not trigger more crashes.I debugged through the
allocation code including the Win32 code and it seems to work well. I have
also tried disabling the MemGroup.FreeMem cache which did not matter.

An added assert for no Stubs to the end of RuntimeDyldImpl::loadObject
      processRelocationRef(SectionID, *i, *obj, LocalSections, LocalSymbols,
   Stubs);
      assert(!Stubs.size());
indeed caught nothing = no stubs created.

Disabling (de)registerEH did not help.

Looking at relocations and sections printouts, the exception is:

Unhandled exception at 0x0A3600D1 :
0xC0000005: Access violation writing location 0x00BC7680.

which is right after the start of .text:

emitSection SectionID: 1 Name: .text obj addr: 0A3F1350 new addr: 0A360000
DataSize: 253203 StubBufSize: 0 Allocate: 253203
...
Resolving relocations Section #1        0A360000

so at least it is running code but tries to write a wrong location.
Another run exhibits similar crash, still in .text but somewhat later.

I have checked and the function address I'm running is located in .text
towards the end, as expected since it's the last function added to the
Module.

Also I speculated that if it crashes when .text crosses 128K but no, it
happens when it's larger.

I had attached gdb to the process hoping it will show more information but
it showed even less information than the Visual C++ debugger.

Out of ideas...

Yaron



2013/10/22 Kaylor, Andrew <andrew.kaylor at intel.com>
>  I would guess that it’s crashing somewhere in the generated code.  On
> Windows we don’t have a way to get call stacks to the generated code
> (though if you want to try it on Linux, that should work).  You can
> probably look at the address where the crash is occurring and verify that
> it is in the generated code.****
>
> ** **
>
> There are a couple of things I would look for.****
>
> ** **
>
> First, I’d take a look at the SectionMemoryManager allocation handling.
> The fact that the problem is code size dependent strongly points in this
> direction.  It may be that SectionMemoryManager does something wrong when
> it hits a page boundary or something.****
>
> ** **
>
> Second, I’d look at the relocation processing.  If it is generating any
> stubs, that would be a potential problem spot, but it shouldn’t be
> generating any stubs.  So the obvious thing to look at is whether any of
> the relocations are writing to the spot where the crash occurs.****
>
> ** **
>
> -Andy****
>
> ** **
>
> ** **
>
> *From:* Yaron Keren [mailto:yaron.keren at gmail.com]
> *Sent:* Tuesday, October 22, 2013 10:17 AM
> *To:* Kaylor, Andrew
> *Cc:* <llvmdev at cs.uiuc.edu>
> *Subject:* Re: Size limitations in MCJIT / ELF Dynamic Linker/ ELF
> codegen?****
>
> ** **
>
> OS is Windows 7 64 bit OS, compiler is 32 bit Visual C++ 2012 with 32 bit.
> ****
>
> The target which is i686-pc-mingw32-elf so I can use the ELF dynamic
> loader. ****
>
> Code model, relocation model and and memory manager are whatever default
> for this - did not modify.****
>
> ** **
>
> The Module comes from clang. The source is 1000 or more lines repeating
> C++ code in one big function:****
>
> ** **
>
>   A+1;****
>
>   A*B.t();****
>
> ** **
>
> where A and B are matrices from Armadillo http://arma.sourceforge.net/.
> This a stress and performance test due to the large number of EH and
> temporary objects created.****
>
> ** **
>
> I am using the Engine Builder and MCJIT unmodified (except the
> multi-modules patches which are not relevant as there is only one module)
> like this:****
>
> ** **
>
>   OwningPtr<llvm::ExecutionEngine> EE(llvm::EngineBuilder(M)****
>
>                                           .setErrorStr(&Error)****
>
>                                           .setUseMCJIT(true)****
>
>                                           .create());****
>
> ** **
>
> to run the function either ****
>
> ** **
>
>   llvm::Function *F = M->getFunction(Name);****
>
>   void *FN = EE->getPointerToFunction(F);****
>
> or****
>
>   uint64_t FN = EE->getFunctionAddress(Name);****
>
> ** **
>
> followed by ****
>
> ** **
>
>  ((void (*)())FN)();****
>
> or****
>
>   EE->runFunction(F, std::vector<llvm::GenericValue>());****
>
> ** **
>
> all work the same with smaller about 1000 lines of the above code module
> and crash the same with more code. The call stack is unhelpful Visual C++
> says: Frames below may be incorrect and/or missing which indicates a real
> problem with it. I have tried to provide less stack space (default is 10M)
> for the compiled program without any change.****
>
> ** **
>
> Yaron****
>
> ** **
>
> ** **
>
> 2013/10/22 Kaylor, Andrew <andrew.kaylor at intel.com>****
>
>   I’m not aware of such a limitation.****
>
>  ****
>
> What architecture, code model and relocation model are you using?  Are
> you using the SectionMemoryManager?****
>
>  ****
>
> -Andy****
>
>  ****
>
> *From**:* Yaron Keren [mailto:yaron.keren at gmail.com]
> *Sent**:* Tuesday, October 22, 2013 8:12 AM
> *To**:* <llvmdev at cs.uiuc.edu>; Kaylor, Andrew
> *Subject**:* Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?*
> ***
>
>  ****
>
> I'm running in MCJIT a module generated from one C++ function. Every
line
> of the source function uses C++ classes and may throw an exception. As
> long as there are less than (about) 1000 lines, everything works. With more
> lines the compiled code crashes when running it, with no sensible stack
> trace.****
>
>  ****
>
> Is there any kind of hard-coded size limitation in MCJIT / ELF Dynamic
> Linker / ELF codegen / number of EH states in a function ? ****
>
>  ****
>
> I did browse the code but could not find anything obvious. ****
>
>  ****
>
> Yaron****
>
>  ****
>
>  ** **
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131022/e048d133/attachment.html>

Possibly Parallel Threads

Search for more possibly parallel threads

llvm dev - Oct 2013 - [LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?

[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?

[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?

[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?

Possibly Parallel Threads