search for: map_32bit

Can you try it without the MAP_32BIT part? It won't be as reliable, but if the memory addresses it is asking for are available it could work. I agree that there are good reasons not to lock in on a single memory address, but I'm curious as to what other obstacles might be lurking behind the ones we know about. If the patch...

...cussed yesterday on IRC regarding TLS with MCJIT, I've put together the attached experimental patch. This patch makes three changes: 1. SectionMemoryManager is changed to request memory below the 2GB boundary by default. 2. sys::Memory::allocateMappedMemory is changed to set the MAP_32BIT flag if the requested "near" block is below the 2GB boundary. 3. RuntimeDyldELF is changed to recognize the possibility of external data symbols. Of these changes, items 2 and 3 are probably reasonable things to commit into trunk, and depending on how this turns out I will do so....

Hi, Unfortunately, I can't compile this patch. MAP_32BIT is a Linuxism that doesn't work on FreeBSD (or OS X, or, as far as I can tell, anywhere except Linux). We can consider adding something similar to FreeBSD (although I'm hesitant to encourage anything that increases the determinism of the memory layout of JITed code, for security reasons),...

...lt;= INT32_MAX && (int64_t)Value >= INT32_MIN))), function resolveX86_64Relocation, file ../lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp, line 222. David On 9 May 2013, at 13:58, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > Can you try it without the MAP_32BIT part? It won't be as reliable, but if the memory addresses it is asking for are available it could work. > > I agree that there are good reasons not to lock in on a single memory address, but I'm curious as to what other obstacles might be lurking behind the ones we know about. If...

..._t)Value >= INT32_MIN))), function resolveX86_64Relocation, file > ../lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp, line 222. > > David > > On 9 May 2013, at 13:58, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > > > Can you try it without the MAP_32BIT part? It won't be as reliable, but > if the memory addresses it is asking for are available it could work. > > > > I agree that there are good reasons not to lock in on a single memory > address, but I'm curious as to what other obstacles might be lurking behind > the...

...lt;= INT32_MAX && (int64_t)Value >= INT32_MIN))), function resolveX86_64Relocation, file ../lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp, line 222. David On 9 May 2013, at 13:58, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > Can you try it without the MAP_32BIT part? It won't be as reliable, but if the memory addresses it is asking for are available it could work. > > I agree that there are good reasons not to lock in on a single memory address, but I'm curious as to what other obstacles might be lurking behind the ones we know about. If...

...-release Mandriva Linux release 2008.0 (Official) for x86_64 I can't execute functions Jitted by LLVM that call back functions in the main program, if the jit is run from a .so library. I replaced LLVM with an hand made jit, and after tinkering with it, I found that I had to use special flags (MAP_32BIT) into mmap to get a segment of memory "near to the code" enough so that calls with 32 bit displacements jumped to the right address cur_segm=mmap (0, segm_size, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT, -1, 0); Strangely, this problem happened only when loa...

...interpreter entered unexpected state, exiting. |This is because BQN tries to allocate memory for a JIT near itself and also in the lower 32 bits.| u64 near = (u64)&bqn_exec; u64 MAX_DIST = 1ULL<<30; mmap(NULL, sz, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_NORESERVE|MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT, -1, 0); |However, |&bqn_exec| seems to be 0x7...||i.e. libcbqn.so is being loaded to a high address. Why is this? Is there some way to request that it and its symbols be loaded to lower addresses? I have never had this happen when using dlopen and dlsym!| | Thanks! Vanessa McHale| | [[al...

Hi, Recently I hit an issue that LLJIT crashes when CodeGenOpt::Less or higher is given. After investigation, it turned out that the issue is some global constant string in the IR, like > @.str.117 = private unnamed_addr constant [9 x i8] c"lineitem\00", align 1 > becomes an invalid pointer in the generated code. > $1 = 0xf7fab054 <error: Cannot access memory at address

...> That should only be the x86-64 JIT. If the x86-32 JIT does that, it's > definitely a bug. For x86-64, it's required unless the > JITMemoryManager can guarantee that it only allocates code within 2GB > of the text segment. > > Our memory manager allocates memory using the MAP_32BIT flag to mmap, so it can guarantee that it is a 32 bit address. > > This causes problems for the usage of LLVM in JITs > > since the JIT can no longer patch the callsite after the callee have been > > compiled. > > As far as I know, the JIT only tries to patch the callsite...

Howard Chu wrote: > Chris Lattner wrote: >> >> On Oct 26, 2009, at 1:00 AM, Howard Chu wrote: >> >>> Hi, just read the LLVM 2.6 release announcement, the bit about llvm- >>> mc caught >>> my attention. I've been looking for a tool to disassemble x86 object >>> files >>> into an IR and then reassemble them into x86_64 object

On Tue, Dec 15, 2009 at 1:05 AM, Zoltan Varga <vargaz at gmail.com> wrote: > Hi, > > After this commit: > http://llvm.org/viewvc/llvm-project?view=rev&revision=88984 > > the X86 JIT no longer emits calls using call <ADDR>, but always uses mov > REG, <ADDR>, call *REG. That should only be the x86-64 JIT. If the x86-32 JIT does that, it's definitely a

Chris Lattner wrote: > > On Oct 26, 2009, at 1:00 AM, Howard Chu wrote: > >> Hi, just read the LLVM 2.6 release announcement, the bit about llvm- >> mc caught >> my attention. I've been looking for a tool to disassemble x86 object >> files >> into an IR and then reassemble them into x86_64 object code. The >> immediate use >> for them would be

Hi, After this commit: http://llvm.org/viewvc/llvm-project?view=rev&revision=88984 the X86 JIT no longer emits calls using call <ADDR>, but always uses mov REG, <ADDR>, call *REG. This causes problems for the usage of LLVM in JITs since the JIT can no longer patch the callsite after the callee have been compiled. According to the comments for the commit, this was done to fix the

...ssie Bug #697698 [ustr] broken configury with glibc headers moved to the multiarch location Added tag(s) jessie. > tags 554931 + jessie Bug #554931 [src:kanjisaver] FTBFS with binutils-gold Added tag(s) jessie. > tags 651626 + jessie Bug #651626 [src:pearpc] pearpc: FTBFS(kfreebsd-amd64):'MAP_32BIT' was not declared in this scope Added tag(s) jessie. > tags 617012 + jessie Bug #617012 [src:python-libpcap] python-libpcap: deprecation of dh_pycentral, please use dh_python2 Added tag(s) jessie. > tags 650827 + jessie Bug #650827 [qcake] embedds glee library Added tag(s) jessie. > ta...