search for: machinecodeinfo

...ently planning right now on doing exactly the same things as you. I haven't yet had a chance to implement the code, but I can point you to how I currently believe you can get access to what you need. If you take a look at the code for the implementation of lvm::JIT::runJITOnFunction(Function *, MachineCodeInfo *), you'll see that if a MachineCodeInfo parameter is supplied, it is populated via a call to setAddress and setSize via the registration of a JITEventListener on the Jitting of the given function. I'm almost certain this is the address and size that is needed by the disassembler. You then...

...ently planning right now on doing exactly the same things as you. I haven't yet had a chance to implement the code, but I can point you to how I currently believe you can get access to what you need. If you take a look at the code for the implementation of lvm::JIT::runJITOnFunction(Function *, MachineCodeInfo *), you'll see that if a MachineCodeInfo parameter is supplied, it is populated via a call to setAddress and setSize via the registration of a JITEventListener on the Jitting of the given function. I'm almost certain this is the address and size that is needed by the disassembler. You then...

Thanks Reid - I'm on Windows. I guess I just assumed I was missing something obvious in how to hook up the JIT and disassembler! Given the nice looking disassembly code I found, I thought people would be doing it all the time :-) b. On Tue, Jul 6, 2010 at 8:41 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > If you're on a recent flavor of Linux, you may be able to just

...relocations on it? How can that work? Are you just assuming that everything winds up at the same addresses? Or is everything PC-relative on your platform, so all that matters is that globals and the code are in the same relative positions? How are you getting the size of the code you need to copy? MachineCodeInfo didn't exist when you wrote this patch, so I assume you've written your own JITMemoryManager. Even then, if you JIT more than one function, and they share any globals, you have to deal with multiple calls into the MemoryManager and functions that use globals allocated inside other buffers....

...ny changes to the existing client code. Beyond that, I am not the kind of person who thinks there's only one way to do things; I won't object to what you do as long as it doesn't break what we're using now. > How are you getting the size of the code you need to copy? > MachineCodeInfo didn't exist when you wrote this patch, so I assume > you've written your own JITMemoryManager. Even then, if you JIT more > than one function, and they share any globals, you have to deal with > multiple calls into the MemoryManager and functions that use globals > allocated in...

On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: > So I (think I) found a bug in the JIT: > http://llvm.org/bugs/show_bug.cgi?id=4483 > > Basically, globals used by a function are allocated in the same buffer > as the first code that uses it. However, when you free the machine > code, you also free the memory holding the global's data. The address > is still in the

So I (think I) found a bug in the JIT: http://llvm.org/bugs/show_bug.cgi?id=4483 Basically, globals used by a function are allocated in the same buffer as the first code that uses it. However, when you free the machine code, you also free the memory holding the global's data. The address is still in the GlobalValue map, so any other code using that global will access freed memory, which

.../LiveVariables.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/MachORelocation.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/MachineBasicBlock.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/MachineCodeEmitter.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/MachineCodeInfo.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/MachineConstantPool.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/MachineDominators.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/MachineFrameInfo.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/MachineFunct...

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel