search for: allocatespace

> + /// allocateSpace - reserves space in the current block if any, or > + /// allocate a new one of the given size + virtual void > *allocateSpace(intptr_t Size, unsigned Alignment); + > Please capitalize "reserves". ok. > + /// allocateSpace - general-purpose space allocator > Better commen...

Thanks Nuno and Dale. Some comments: + /// allocateSpace - reserves space in the current block if any, or + /// allocate a new one of the given size + virtual void *allocateSpace(intptr_t Size, unsigned Alignment); + Please capitalize "reserves". + /// allocateSpace - general-purpose space allocator Better comments please. :-) Also please end...

...;t update the data structures the JITEmitter relies > on. In the usual case, the JITEmitter calls into JIT and updates its > own data structures, so that case works fine. exactly! :) Thank you for summarizing. I hope others can now follow this description. > I think adding a smarter allocateSpace to JITEmitter is the right > general idea, and your patch looks OK. I'd like to get another pair > of eyes on it though, as I find this area not straightfoward:) Please > run the testsuite before committing. Yes, I would also appreciate more reviewers. The JIT's code is particu...

On Oct 16, 2008, at 11:29 AM, Nuno Lopes wrote: >> + /// allocateSpace - reserves space in the current block if any, or >> + /// allocate a new one of the given size + virtual void >> *allocateSpace(intptr_t Size, unsigned Alignment); + >> Please capitalize "reserves". > > ok. > > >> + /// allocateSpace - general-purpose s...

On Tue, Oct 6, 2009 at 5:49 PM, Reid Kleckner <rnk at mit.edu> wrote: >> Also, the null pointer is coming from a call to JCE->allocateSpace(). >> This is a virtual function; I'm trying to discover what subclass it >> is. > > So, there's JITEmitter::allocateSpace which overrides > JITCodeEmitter::allocateSpace(), but *most* of the time it just calls > JITCodeEmitter::allocateSpace().  In particular, it do...

> 6. When ExecutionEngine::create was called with parameter > "GVsWithCode" set to its default value of true, I got a segfault when > trying to get a pointer to one of my globals.  JIT::getMemoryForGV was > returning NULL in that case.  Explicitly passing false for > "GVsWithCode" cleared it up. That's no good. Could you send me a stack trace and explain

...rray trick seems to work ... sort of. My question though is: 1) In JITDwarfEmitter.cpp these GlobalVariables are emitted with: JCE->emitInt64((intptr_t)Jit.getOrEmitGlobalVariable(GV)); (in JITDwarfEmitter::EmitExceptionTable) 2) The allocated emitted space is calculated by: JITCodeEmitter::allocateSpace(...) as eventually called by getOrEmitGlobalVariable(...) 3) If the correctly sized buffer was already allocated, and alignment did not affect the current buffer pointer, JITCodeEmitter::allocateSpace(...) returns the current buffer pointer (CurBufferPtr), BEFORE this pointer is offset by the size...

...gnment); } virtual void endFunctionBody(const llvm::Function *F, uint8_t *FunctionStart, uint8_t *FunctionEnd) { return mgr()->endFunctionBody(F, FunctionStart, FunctionEnd); } virtual uint8_t *allocateSpace(intptr_t Size, unsigned Alignment) { return mgr()->allocateSpace(Size, Alignment); } virtual uint8_t *allocateGlobal(uintptr_t Size, unsigned Alignment) { return mgr()->allocateGlobal(Size, Alignment); } virtual void deallocateFunctionBody(void *Body)...

...I have fixed this bug by adding an additional check after all relocations have been completed. In the process of fixing this bug, I happened to look through the code in MachineCodeEmitter.h. The buffer size checks in MachineCodeEmitter.h all suffer from an integer overflow bug. For example in allocateSpace the code reads: // Allocate the space. CurBufferPtr += Size; // Check for buffer overflow. if (CurBufferPtr >= BufferEnd) { This is wrong because Size + CurBufferPtr can cause an integer overflow and thus appear to be less than BufferEnd. The correct way to check for th...

...dditional check after all relocations have been completed. >> In the process of fixing this bug, I happened to look through the code >> in MachineCodeEmitter.h. The buffer size checks in >> MachineCodeEmitter.h all suffer from an integer overflow bug. For >> example in allocateSpace the code reads: >> >> // Allocate the space. >> CurBufferPtr += Size; >> >> // Check for buffer overflow. >> if (CurBufferPtr >= BufferEnd) { >> >> This is wrong because Size + CurBufferPtr can cause an integer >> overflow and...

...virtual void endFunctionBody(const llvm::Function *F, > uint8_t *FunctionStart, > uint8_t *FunctionEnd) { > return mgr()->endFunctionBody(F, FunctionStart, FunctionEnd); > } > virtual uint8_t *allocateSpace(intptr_t Size, unsigned Alignment) { > return mgr()->allocateSpace(Size, Alignment); > } > virtual uint8_t *allocateGlobal(uintptr_t Size, unsigned Alignment) { > return mgr()->allocateGlobal(Size, Alignment); > } > virtual void deallocate...

...unctionBody(const llvm::Function *F, >> uint8_t *FunctionStart, >> uint8_t *FunctionEnd) { >> return mgr()->endFunctionBody(F, FunctionStart, FunctionEnd); >> } >> virtual uint8_t *allocateSpace(intptr_t Size, unsigned Alignment) { >> return mgr()->allocateSpace(Size, Alignment); >> } >> virtual uint8_t *allocateGlobal(uintptr_t Size, unsigned Alignment) { >> return mgr()->allocateGlobal(Size, Alignment); >> } >>...

...you guys because you seem to know what should and what shouldn't work, given your recent changes to the XFAILs. Feel free to exclude yourselves, or include other folks. I'm having a problem with a self-hosting ARM bot described here: http://llvm.org/bugs/show_bug.cgi?id=18057 Basically, allocateSpace() sometimes works, sometimes doesn't. I couldn't see much wrong with the code, and the call graph looks valid, so I'm guessing it's something in the higher logic (message passing) that is non-deterministically failing. I even tried to run manually several times in a row and sometim...

...> adding an additional check after all relocations have been completed. > In the process of fixing this bug, I happened to look through the code > in MachineCodeEmitter.h. The buffer size checks in > MachineCodeEmitter.h all suffer from an integer overflow bug. For > example in allocateSpace the code reads: > > // Allocate the space. > CurBufferPtr += Size; > > // Check for buffer overflow. > if (CurBufferPtr >= BufferEnd) { > > This is wrong because Size + CurBufferPtr can cause an integer > overflow and thus appear to be less than BufferE...

Hi everyone, vmkit requires to know the size of a jitted method before emitting the method. This allows to allocate the correct size for the method. The attached patch creates this functionality when the flag SizedMemoryCode is on. In order to implement this functionality, i had to virtualize some MachineCodeEmitter functions. Is it OK to commit the patch? Thanks, Nicolas --------------

...es the MachineCodeEmitter directly. Thus, if you call it from outside the JITEmitter, it won't update the data structures the JITEmitter relies on. In the usual case, the JITEmitter calls into JIT and updates its own data structures, so that case works fine. I think adding a smarter allocateSpace to JITEmitter is the right general idea, and your patch looks OK. I'd like to get another pair of eyes on it though, as I find this area not straightfoward:) Please run the testsuite before committing. Thanks for analyzing this and the test case. > The problem only happens when ca...

...); >> + unsigned Size = CPE.Offset; >> + const Type *Ty = CPE.isMachineConstantPoolEntry() >> + ? CPE.Val.MachineCPVal->getType() : CPE.Val.ConstVal->getType(); >> + Size += Fn->getTarget().getTargetData()->getABITypeSize(Ty); >> + ConstantPoolBase = allocateSpace(Size, 1 << MCP- >> >>> getConstantPoolAlignment()); >>> >> + ConstantPool = MCP; >> +} >> + >> +void SizeEmitter::initJumpTableInfo(MachineJumpTableInfo *MJTI) { >> + const std::vector<MachineJumpTableEntry> &JT =...

...PE = Constants.back(); > + unsigned Size = CPE.Offset; > + const Type *Ty = CPE.isMachineConstantPoolEntry() > + ? CPE.Val.MachineCPVal->getType() : CPE.Val.ConstVal->getType(); > + Size += Fn->getTarget().getTargetData()->getABITypeSize(Ty); > + ConstantPoolBase = allocateSpace(Size, 1 << MCP- > >getConstantPoolAlignment()); > + ConstantPool = MCP; > +} > + > +void SizeEmitter::initJumpTableInfo(MachineJumpTableInfo *MJTI) { > + const std::vector<MachineJumpTableEntry> &JT = MJTI- > >getJumpTables(); > + if (JT.empty()) r...

...r all relocations have been >>> completed. In the process of fixing this bug, I happened to look >>> through the code in MachineCodeEmitter.h. The buffer size checks >>> in MachineCodeEmitter.h all suffer from an integer overflow bug. >>> For example in allocateSpace the code reads: >>> >>> // Allocate the space. >>> CurBufferPtr += Size; >>> // Check for buffer overflow. >>> if (CurBufferPtr >= BufferEnd) { >>> >>> This is wrong because Size + CurBufferPtr can cause an integer >&g...

...CPE.Offset; >>> + const Type *Ty = CPE.isMachineConstantPoolEntry() >>> + ? CPE.Val.MachineCPVal->getType() : CPE.Val.ConstVal- >>> >getType(); >>> + Size += Fn->getTarget().getTargetData()->getABITypeSize(Ty); >>> + ConstantPoolBase = allocateSpace(Size, 1 << MCP- >>> >>>> getConstantPoolAlignment()); >>>> >>> + ConstantPool = MCP; >>> +} >>> + >>> +void SizeEmitter::initJumpTableInfo(MachineJumpTableInfo *MJTI) { >>> + const std::vector<MachineJumpTableE...