search for: recordingmemorymanager

Hi Andrew, Looks like RecordingMemoryManager in lli just calls malloc() and it would be strange to make assumptions (or enforce) that the difference between two returned pointers in 64-bit virtual address space will be fit into 32 bits. Can we do smth similar to what Adhemerval proposed (see the special case in processRelocationRef for ELF::R...

...el.com>wrote: > Yes, at some point we definitely should introduce stubs as a last resort > for x86-64 relocations when the sections are too far apart, but I’d like to > avoid it whenever possible.**** > > ** ** > > What I meant in my previous message was that I’d have > RecordingMemoryManager use something other than malloc (such as the memory > API used by SectionMemoryManager) to keep section near one another. > Ok, I see your point. Should I open the bug to track this, or you'll have a chance to look at this issue soon? > **** > > ** ** > > -Andy**** >...

Yes, at some point we definitely should introduce stubs as a last resort for x86-64 relocations when the sections are too far apart, but I'd like to avoid it whenever possible. What I meant in my previous message was that I'd have RecordingMemoryManager use something other than malloc (such as the memory API used by SectionMemoryManager) to keep section near one another. -Andy From: Alexey Samsonov [mailto:samsonov at google.com] Sent: Wednesday, January 30, 2013 3:59 AM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: Re: Assertions...

...tel.com<mailto:andrew.kaylor at intel.com>> wrote: Yes, at some point we definitely should introduce stubs as a last resort for x86-64 relocations when the sections are too far apart, but I'd like to avoid it whenever possible. What I meant in my previous message was that I'd have RecordingMemoryManager use something other than malloc (such as the memory API used by SectionMemoryManager) to keep section near one another. Ok, I see your point. Should I open the bug to track this, or you'll have a chance to look at this issue soon? -Andy From: Alexey Samsonov [mailto:samsonov at google.com&l...

Hi Alexey, I think the most likely way to resolve this is to have the RecordingMemoryManager do something more complex to manage its allocations in such a way as to guarantee that they are all within proximity of one another. The code that is asserting is handling a relocation where code was generated to use a 32-bit relative offset in 64-bit code. If the two sections involved really are...

Hi! I'm trying to run LLVM test suite under AddressSanitizer and get test failures in: LLVM :: ExecutionEngine/MCJIT/simpletest-remote.ll LLVM :: ExecutionEngine/MCJIT/test-data-align-remote.ll LLVM :: ExecutionEngine/MCJIT/test-fp-no-external-funcs-remote.ll LLVM :: ExecutionEngine/MCJIT/test-global-init-nonzero-remote.ll All of them fail with assertion: lli:

..._build/llvm.native.x86_64-w64-mingw32/Release/lib -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -o /usr/home/solskogen/obj/_build/llvm.native.x86_64-w64-mingw32/Release/bin/lli.exe /usr/home/solskogen/obj/_build/llvm.native.x86_64-w64-mingw32/tools/lli/Release/RecordingMemoryManager.o /usr/home/solskogen/obj/_build/llvm.native.x86_64-w64-mingw32/tools/lli/Release/RemoteTarget.o /usr/home/solskogen/obj/_build/llvm.native.x86_64-w64-mingw32/tools/lli/Release/lli.o \ -lLLVMAsmParser -lLLVMBitReader -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Ut...