similar to: [LLVMdev] exposing container-specific features in the Object library

On Thu, Jul 4, 2013 at 10:21 PM, Charles Davis <cdavis5x at gmail.com> wrote: > > On Jul 4, 2013, at 10:22 PM, 罗勇刚(Yonggang Luo) wrote: > > > 在 2013-7-4 下午8:53，"Charles Davis" <cdavis5x at gmail.com>写道： > > > > > > On Jul 4, 2013, at 1:43 AM, 罗勇刚(Yonggang Luo) wrote: > > > > > LLVM is a modularized software system, so I hope

The MachO handling isn’t always straightforward in that it has a lot of bit fields to handle while it’s also trying to accommodate the format abstractions baked into the interfaces. The actual relocation type gets extracted in the RuntimeDyldMachO::resolveRelocation function (RuntimeDyldMachO.cpp:32) before it is passed on to the architecture-specific handlers. So the mask you mentioned is

Submitted to bugzilla as PR 15729 From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew Sent: Thursday, April 11, 2013 1:13 PM To: Weiss, Eran Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Migration from JIT to MCJIT Thanks, Eran. I’m not sure how soon I’ll have a solution for you, but it’s on my to-do list now. I’ll also create a bugzilla

Eran, Is there any chance you could boil this down to a small reproducer? I’ve got a mid-to-long-term goal of getting rid of the ugliness in LLDB that Jim mentioned, and fixing your problem would be a good first step. Thanks, Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Wednesday, April 10, 2013 4:19 PM To: Kaylor, Andrew; Jiong Wang Cc: Weiss, Eran; llvmdev at cs.uiuc.edu

Thanks, Eran. I’m not sure how soon I’ll have a solution for you, but it’s on my to-do list now. I’ll also create a bugzilla record for this problem. -Andy From: Weiss, Eran [mailto:Eran.Weiss at emc.com] Sent: Thursday, April 11, 2013 12:40 AM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu; Jim Grosbach; Jiong Wang Subject: Re: [LLVMdev] Migration from JIT to MCJIT Andrew, I've attached

Existing clients (LLDB) deal with externals by resolving them to constant function pointers that are referenced in the IR. That’s obviously ugly as hell, but it gets things done. The old JIT was able to simplify things because it assumed the JITed code was running in the same process as the JIT compiler. The MCJIT doesn’t assume that, so it has to handle more possibilities. For example, that the

Yaron, Did you find a way around the problem? It looks like the problem comes before processFDE because by the time it gets to processFDE the eh_frame data is already corrupted. Does ELF and MachO share the same eh_frame format? I am developing this code in parallel on an Ubuntu Linux system but I haven't tried to run it on there for a couple of weeks. I'll bring it up to date and

Andrew, I've attached a small reproduction of the issue. Reproduce by: $ /usr/bin/g++ `llvm-config --cxxflags` -g -m32 -c mcjit_external_symbol.cpp $ /usr/bin/g++ `llvm-config --ldflags` -g -m32 -o mcjit_external_symbol mcjit_external_symbol.o `llvm-config --libs all` $ ./mcjit_external_symbol verifying... LLVM ERROR: Program used external function '_external' which could not be

So, for this test case: extern "C" void shouldBeUnconditional(); extern "C" void shouldBeConditional(); extern "C" void otherCall(); void testFn(bool Bool1, bool Bool2) { Bool1 |= Bool2; shouldBeUnconditional(); if (Bool1) shouldBeConditional(); if (Bool2) { otherCall(); if (Bool1) otherCall(); } } MSVC generates this buggy asm: $ cl -c

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:

Thanks. I am just trying to find a relocation and linking design for Hexagon architecture, whether to follow the MIPS style of relocation or other architecture style of relocation. Thats my question . Thats why i was asking about the functions and their differences Please guide. Thanks, Siddharth On Fri, Apr 21, 2017 at 8:37 PM, mats petersson <mats at planetcatfish.com> wrote: > If

Hi, I had similar problems with EH in ELF in RTDyldMemoryManager::registerEHFrames() calling __register_frame(). I'm not sure these problems are related to this problem since your crash happens in RuntimeDyldMachO::registerEHFrames() in its own processFDE (there are two functions named processFDE(), one in RuntimeDyldMachO.cpp and one in RTDyldMemoryManager.cpp) *before*

On Fri, May 29, 2015 at 4:06 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Hi everyone, > > Having proper error handling in LLVM's Object parsing library is a nice > thing by itself, but it would additionally allow us to find bugs by fuzzing > (see r238451 that adds llvm-dwarfdump-fuzzer tool), for which the clean > input validation is essential. > > This

Hi Christian, Thanks for sharing this. Yaron Keren has been investigating some problems in the EH frame registration code recently, and I think this may be related. It at least sounds similar to the type of variations in behavior based on code size that Yaron was seeing. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of

On 29 May 2015 at 19:06, Alexey Samsonov <vonosmas at gmail.com> wrote: > Hi everyone, > > Having proper error handling in LLVM's Object parsing library is a nice > thing by itself, but it would additionally allow us to find bugs by fuzzing > (see r238451 that adds llvm-dwarfdump-fuzzer tool), for which the clean > input validation is essential. > > This is a

Hi, A few tests seem broken for a long time, some for more than a month. Would it possible for respective owners to take a look please? I'm at checkout 133a7e631cee97965e310f0d110739217427fd3d, compiling on Windows 10. These tests fail with Visual Studio 2019: Failing Tests (7): Clang Tools :: clang-tidy/checkers/cert-mem57-cpp-cpp17.cpp Clang Tools ::

I switched my Common Lisp compiler to use MCJIT on the weekend and ran into a weird problem compiling one particular function. It crashes with an EXC_BAD_ACCESS error in MCJIT::finalizeObject when calling processFDE. The weird part is that the function does not appear to do anything special and I've whittled it down to the minimum size that still causes the crash. If I remove even one

Thank you for the help. The relocation type value is anded with 0xffffffffL. (RuntimeDyldMachO.cpp:214) Maybe this mask should be different? Anyway, it seems like this relocation isn't implemented. (RuntimeDyldMachO.cpp:104) From: Jiong Wang <jiwang at tilera.com<mailto:jiwang at tilera.com>> Date: Tue, 9 Apr 2013 09:42:03 -0400 To: Eran Weiss <eran.weiss at

> As far as I know, ObjectFile is either COFF, ELF or MachO format, > statically compiled. But the pass manager for applying optimisation > passes works only on llvm-ir. I would not need to apply optimisations on the parts of the program in the object file. These are meant to be optimised beforehand. The only parts I want to run passes on are specific function that I know

On 19 September 2013 11:59, Jason Holajter <jholajter at arxan.com> wrote: > Hi, > > The behavior of llvm-ar appears to have changed such that the archive symbol > table no longer contains symbols contained within bitcode modules in the > archive. This behavior appears to have been changed with revision 184083 > when the internal implementation of llvm-ar was changed from