search for: runtimedyldelf

...akaylor Date: Mon Aug 19 18:27:43 2013 New Revision: 188726 URL: http://llvm.org/viewvc/llvm-project?rev=188726&view=rev Log: Adding PIC support for ELF on x86_64 platforms Modified: llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.h llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h Modified: llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld....

...r(); With this set of functions it attempts to JIT something at least. I run into a segfault, valgrind reports the following: ==27130== Process terminating with default action of signal 11 (SIGSEGV) ==27130== Bad permissions for mapped region at address 0xEAF02F7 ==27130== at 0xEAF031F: llvm::RuntimeDyldELF::resolveX86_64Relocation(llvm::SectionEntry const&, unsigned long, unsigned long, unsigned int, long, unsigned long) (RuntimeDyldELF.cpp:213) ==27130== by 0xEAF260F: llvm::RuntimeDyldELF::resolveRelocation(llvm::SectionEntry const&, unsigned long, unsigned long, unsigned int, long, unsig...

...ons it attempts to JIT something at least. > I run into a segfault, valgrind reports the following: > > ==27130== Process terminating with default action of signal 11 (SIGSEGV) > ==27130== Bad permissions for mapped region at address 0xEAF02F7 > ==27130== at 0xEAF031F: > llvm::RuntimeDyldELF::resolveX86_64Relocation(llvm::SectionEntry const&, > unsigned long, unsigned long, unsigned int, long, unsigned long) > (RuntimeDyldELF.cpp:213) > ==27130== by 0xEAF260F: > llvm::RuntimeDyldELF::resolveRelocation(llvm::SectionEntry const&, unsigned > long, unsigned long,...

...ote.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: /usr/local/google/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:230: void llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry &, uint64_t, uint64_t, uint32_t, int64_t): Assertion `RealOffset <= (2147483647) && RealOffset >= (-2147483647-1)' failed. The reason is that AddressSanitizer replaces system malloc with its...

It's probably best to open a bug. -Andy From: Alexey Samsonov [mailto:samsonov at google.com] Sent: Thursday, January 31, 2013 12:27 AM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: Re: Assertions in RuntimeDyldELF in ExecutionEngine/MCJIT tests On Wed, Jan 30, 2013 at 8:34 PM, Kaylor, Andrew <andrew.kaylor at intel.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, bu...

...at this issue soon? > **** > > ** ** > > -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 in RuntimeDyldELF in ExecutionEngine/MCJIT tests > **** > > ** ** > > 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****...

...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 in RuntimeDyldELF in ExecutionEngine/MCJIT tests 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 wha...

...nitizer case?**** > > ** ** > > Thanks,**** > > Andy**** > > ** ** > > *From:* Alexey Samsonov [mailto:samsonov at google.com] > *Sent:* Tuesday, January 29, 2013 3:36 AM > *To:* LLVM Developers Mailing List > *Cc:* Kaylor, Andrew > *Subject:* Assertions in RuntimeDyldELF in ExecutionEngine/MCJIT tests**** > > ** ** > > Hi!**** > > ** ** > > I'm trying to run LLVM test suite under AddressSanitizer and get test > failures in:**** > > LLVM :: ExecutionEngine/MCJIT/simpletest-remote.ll**** > > LLVM :: ExecutionEngine/M...

...le I can do there. In the meantime, is there any way that you can mark these tests as XFAIL in the sanitizer case? Thanks, Andy From: Alexey Samsonov [mailto:samsonov at google.com] Sent: Tuesday, January 29, 2013 3:36 AM To: LLVM Developers Mailing List Cc: Kaylor, Andrew Subject: Assertions in RuntimeDyldELF in ExecutionEngine/MCJIT tests 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-...

...z/dev/llvm/x64/llvm/test/ExecutionEngine/MCJIT/test-setcond-fp.ll > /dev/null -- Exit Code: 134 Command Output (stderr): -- assertion "RealOffset <= INT32_MAX && RealOffset >= INT32_MIN" failed: file "/cygdrive/z/dev/llvm/x64/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp", line 308, function: void llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry&, uint64_t, uint64_t, uint32_t, int64_t, uint64_t) Stack dump: 0. Program arguments: /cygdrive/z/dev/llvm/x64/static/Release+Asserts/bin/lli -use-mcjit -mtriple=x86_64-unknown-cy...

...> /dev/null > -- > Exit Code: 134 > > Command Output (stderr): > -- > assertion "RealOffset <= INT32_MAX && RealOffset >= INT32_MIN" > failed: file > "/cygdrive/z/dev/llvm/x64/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp", > line 308, function: void > llvm::RuntimeDyldELF::resolveX86_64Relocation(const > llvm::SectionEntry&, uint64_t, uint64_t, uint32_t, int64_t, uint64_t) > Stack dump: > 0. Program arguments: > /cygdrive/z/dev/llvm/x64/static/Release+Asse...

Hello everyone, As part of my quest to add TLS relocation support to MCJIT, I've been taking a closer look at the GOT implementation in RuntimeDyldELF and I believe that is not valid as currently implemented. In particular, I am wondering about the multiple GOT handling support introduced in r192020. If I understand correctly this can make code reuse the GOT table entry in a different object file. This doesn't seem correct to me as there is n...

...commit it to the SVN. Thank you, Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130524/069287d6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: RuntimeDyldELF.cpp_add_thumb_call_relocation.diff Type: application/octet-stream Size: 1079 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130524/069287d6/attachment.obj>

Hi Jonas, > here is a patch to add Thumb call relocation to the dynamic linker. I would be happy if you could commit it to the SVN. Thanks very much for working on this. It looks like a good starting-point, but there are a couple of issues with the patch at the moment. First, it only handles RelValue up to 22 bits (depending on how you count) in size. But on ARMv6T2 onwards the J1 and J2

Hi folks, Three MCJIT tests are failing on both our buildbots (check-all and self-host) and I'm not sure what's the best way to fix it. Some test passes, some not on { A9, A15 } x { Ubuntu 12.10, Ubuntu 12.04 }, the error is: lli: /home/user/devel/llvm/src/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:307: void llvm::RuntimeDyldELF::resolveARMRelocation(const llvm::SectionEntry&, uint64_t, uint32_t, uint32_t, int32_t): Assertion `(*TargetPtr & 0x000F0FFF) == 0' failed. Stack dump: 0. Program arguments: /home/user/devel/llvm/build/bin//lli -use-mcjit -remote-mcjit /home/user/devel...

Thanks for the reply. I was just asking about in general whatever header files are there in Targets/ for different architectures are not including any function except this processRelocationRef() to be used in RuntimeDyldELF.cpp or RuntimeDyldCOFF.cpp or RuntimeDyldMachO.cpp and i think these files are the ones which are actually doing the relocation and linking work. So what purpose do these header files inside Targets/ actually serve. Also they include exception handling in form of exception frames, So can u guide on...

Thanks for reply, it was really helpful. Can u just be more specific and tell about processRelocationRef() and resolveRelocation() in Targets/RuntimeDyld(objectfile format)(arch).h and also in RuntimeDyldELF.cpp and how the same function is implemented in different ways in both the files ? Thanks, Siddharth On Thu, Apr 20, 2017 at 8:16 PM, mats petersson <mats at planetcatfish.com> wrote: > (Again: Please always REPLY to all recipients, including llvm-dev, unless > there is VERY specific...

Hi, We are seeing sporadic crashes since we migrated to MCJIT on Win64. The same tests pass without issues on Mac64 and Linux64. The issue is this assertion failure in RuntimeDyldELF.c: RealOffset <= INT32_MAX && RealOffset >= INT32_MIN I haven't managed to successfully catch the failure in Visual to try and debug it. Any tips on how to make progress? Oh, and we're on LLVM 3.5. Thanks. Ram -------------- next part -------------- An HTML attachment w...

...e of mailing list outageness. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of James Molloy Sent: 21 March 2012 18:21 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] IntervalMap - maximum alignment requirements Hi, I'm debugging a fault seen in RuntimeDyldELF on 32-bit machines, stemming from its use of IntervalMap. The documentation at the top of IntervalMap.h states that it is useful for 4 or 8 byte types, and so RuntimeDyldELF correctly uses it. However, further down the file is this comment: // The root data is either a RootLeaf or a RootB...

Hi, I'm debugging a fault seen in RuntimeDyldELF on 32-bit machines, stemming from its use of IntervalMap. The documentation at the top of IntervalMap.h states that it is useful for 4 or 8 byte types, and so RuntimeDyldELF correctly uses it. However, further down the file is this comment: // The root data is either a RootLeaf or a RootB...