search for: binaryobject

Hi, I need to add a missing include to get current SVN to compile. --- CodeGen/BinaryObject.h (revision 74762) +++ CodeGen/BinaryObject.h (working copy) @@ -18,6 +18,9 @@ #include <string> #include <vector> +#include <stdint.h> + + namespace llvm { My system does not know about uint8_t without this include file. Kind regards, Maurice -------------- next p...

Hi LLVM developers, As PR35281 mentioned: $ llvm-objcopy -O binary llvm-cortex-m7.elf llvm-cortex-m7.bin llvm-objcopy: 'llvm-cortex-m7.elf': The file was not recognized as a valid object file. if (ELFObjectFile<ELF64LE> *o = dyn_cast<ELFObjectFile<ELF64LE>>(&Binary)) https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-objcopy/llvm-objcopy.cpp#L200

...VM do anything to the native code after it is > first emitted?  Does it try rewriting it, for example? That's a good question, and I wish I knew the answer, because if that were the case the entire memory manager could be dramatically simplified to emit code into a resizeable buffer (like a BinaryObject or std::vector<uint8_t>), copy the code into place (wherever the memory manager wants it to go), and then apply the relocations. I suspect that the answer is that the code is not relocatable, or else why would the API be designed this way? OTOH, it may be that the code was not relocatable w...

...the memory management. > 3) Don't really know of any other alternatives :) > > 2 maybe the best compromise option. Its easy to code, removes > templating from the CodeEmitters, and is virtually transparent to > our other DOE work. The only thing it does not write via a > BinaryObject object, so we loose that functionality. > > Hi Aaron, > > I'm sorry for not getting back to you sooner. I work fairly LIFO > and the craziness that has happened since your emails have > distracted me. > > One problem with this patch is that (for example) > X86T...

Hi all, As I understand it, LLVM's JIT memory manager works by allocating a 16Mb block of memory and generating native code into it. Once that block is exhausted no more functions can be JIT compiled. I'm trying to figure out ways to work around this limitation. One idea I had was to use that 16Mb block as a scratch area for generating code. Once a method has been compiled (and

...t;> 3) Don't really know of any other alternatives :) >>> >>> 2 maybe the best compromise option. Its easy to code, removes templating >>> from the CodeEmitters, and is virtually transparent to our other DOE work. >>> The only thing it does not write via a BinaryObject object, so we loose that >>> functionality. >>> >> >> Hi Aaron, >> >> I'm sorry for not getting back to you sooner. I work fairly LIFO and the >> craziness that has happened since your emails have distracted me. >> >> One problem with...

...with a .s parser, a fragment processor, and .o file writer. The main data-structure the .o file writer will work on are "fragments" which (at the end of the assembler) are basically chunks of bytes with an associated section and a list of relocations (which is exactly what llvm::BinaryObject is!). 2. The full assembler should work as a drop in replacement for "as"/"gas". This allows easy testing, and may also be interesting to the BSD folks. I am slightly worried and paranoid about getting different output when using "llvm-gcc -S + as" and using &...

...9;t really know of any other alternatives :) >>>> >>>> 2 maybe the best compromise option. Its easy to code, removes templating >>>> from the CodeEmitters, and is virtually transparent to our other DOE work. >>>> The only thing it does not write via a BinaryObject object, so we loose that >>>> functionality. >>> >>> Hi Aaron, >>> >>> I'm sorry for not getting back to you sooner.  I work fairly LIFO and the >>> craziness that has happened since your emails have distracted me. >>> >>&g...

...lternatives :) > >>>> > >>>> 2 maybe the best compromise option. Its easy to code, removes > templating > >>>> from the CodeEmitters, and is virtually transparent to our other DOE > work. > >>>> The only thing it does not write via a BinaryObject object, so we > loose that > >>>> functionality. > >>> > >>> Hi Aaron, > >>> > >>> I'm sorry for not getting back to you sooner. I work fairly LIFO and > the > >>> craziness that has happened since your emails hav...

...ing: /usr/local/llvm-2.8/include/llvm/CallingConv.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/Analysis.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/AsmPrinter.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/BinaryObject.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/CalcSpillWeights.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/CallingConvLower.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/FastISel.h -- Installing: /usr/local/llvm-2.8/include/llvm/CodeGen/FunctionLoweringInfo.h -...

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