search for: machowrit

Hi! I updated LLVM from CVS today and run into the following error: /lib/CodeGen/MachOWriter.cpp: line 200: no match for function max(unsigned_int_32, unsigned int) the line is Sec.align = std::max(Sec.align, Align); where Sec.align is of type "unsigned_int_32" and Align is of "unsigned int". I use gcc-3.4.4 under cygwin. Сasting of the first parameter to simple u...

...sts. I'm dumping what I understand here, so that we can discuss in detail. I'm using MachO as the example object format, as the ELF code is totally broken and outdated. Lets use the following as the basis for our discussion? There are 3 classes which participate in object file emission: 1. MachOWriter - a MachineFunctionPass, with a donothing runOnMachineFunction. doInitialization and doFinalization are used to emit the object file header and finalize the various object file segments, respectively. The MachOWriter is responsible for creation of MachOCodeEmitter, via it's getMachineCo...

I'll look at these. First scan looks good. Are you able to run some tests? Evan On Feb 28, 2009, at 9:36 AM, Aaron Gray wrote: > I have done a possible cleanup patch for the MachineCodeEmitter, > ELFWriter, and MachOWriter classes. It removes the two > startGVStub(), and finishGVStub() JIT specific methods. > > You may remember the following comments :- > > /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! > > To get rid of these easily turned out to be a semicomplex > modifi...

I have done a possible cleanup patch for the MachineCodeEmitter, ELFWriter, and MachOWriter classes. It removes the two startGVStub(), and finishGVStub() JIT specific methods. You may remember the following comments :- /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! To get rid of these easily turned out to be a semicomplex modification because of the JITInfo classes dep...

Hello Chris Sat, 2 Sep 2006 11:34:55 -0700 (PDT) you wrote: > Intresting, I guess your gcc is treating uint32_t as different from > unsigned. I applied the patch you suggested, thanks! Mingw build is ok here (it uses 3.4.4 version), so, difference is definitely in runtime library. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State

>> Sorry, I disagree actually the MachineCodeEmitter or the >> 'MachineCodeWritter' does not do any file handling at all. Do look at the >> code for the MachineCodeWritter and you will see it only writes to memory >> and if it reaches the end of the allotted memory I believe higher ordered >> logic reallocates a larget buffer and starts again from scratch.

...le in the end. I do think it would be useful if > projects had the option of extending supported formats without having to > modify LLVM itself, but my changes main goal was minimal impact on LLVM > sources. > AFAICT The hooks you sent did not call your code at all. Have a look at the MachOWriter, this is designed to be extendable to other writers. The MCStreamer stuff just needs the same doing probably in TargetAsmBackend. It would be good to have this as a separate patch. This will allow both COFFWriter and ELFWriter as well as the MachOWriter to coexist and be selected by TargetTriple....

Hi all, I have interest in some ideas, some I've seen in the Open project pages (copied straight from there) and some are by my own, they are: 1) Implement MachOWriter and ELFWriter to allow LLVM-based compilers to bypass an external assembler. This may include the idea of an assembler for inline assembly 2) Write a disassembler for machine code that would use TableGen to output MachineInstrs for transformations, optimizations, etc. I read two interesting pape...

Thanks for both of your feedback, I will attempt to make it fit LLVM coding standards better before I resubmit my work. As far as the hooks I put in, they are really only there so I could build the object exporter outside of LLVM, I think having it built directly in like others is preferable in the end. I do think it would be useful if projects had the option of extending supported formats

The current CVS version doesn't compile on Linux: MachOWriter.h:583: error: 'strlcpy' was not declared in this scope Rafael

On 2 May 2010 10:53, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello, Nathan > I'll let others comment on MC hooks, I just made a very brief look > over the contents of the archive. You can find the comments below. > Yes I looked at this and there are several ways but TargetAsmBackend looked the bast place to deal with the MCStreamer choice for different

...hat it would take to port a JVM based language (http://openquark.org) to LLVM. A main motivator though is language/library/platform integration on the Mac (Cocoa, Objective-C, autozone). I'm not too interested in a JIT at this point, but rather native code generation. So far I can see a MachOWriter (with an "AddMachOWriter" in FileWriters.h) and it looks like I get to pass an appropriate TargetMachine to this. I'm wondering if this is expected to be sufficient (added to a pass manager) to be able to output a library on the Mac - whether or not it actually works. I onl...

Hi Nick, On 8/28/2013 6:37 PM, Nick Kledzik wrote > $cat 1.c > int _start() { return 0; } > $gcc -c 1.c > $ld -u myundef 1.o > ==> Does not throw any error, the resolver was hinted that myundef was a undefined weak symbol. > Wow. Reading the gnu ld man page, that is not obvious. How can you make a non-weak undefined on the command line? That is, how can you force and error

...ulti-year projects". I agree with what Holger Schurig said: "[...] So it is actually possible to do this with limited resources (the FPC developer community isn't that large). It just has to be done." Also, Nick Lewycky said that there is ALREADY an unfinished ELFWriter and MachOWriter in lib/Codegen/ ! Owen Anderson wrote: > You, as the developer, install/build binutils in MinGW. > Then you pull the executables out and stick them in the > package that you give your clients. Thus the clients > don't need MinGW. Interesting suggestion, how confident are you...

...llow the streamer & object writer to be built as part of my compiler and not require me to run a build of LLVM every time I changed something. This aproach also allows me to keep this code in source control as I bounce between development machines multiple times a day. > Have a look at the MachOWriter, this is designed to be extendable to other > writers. The MCStreamer stuff just needs the same doing probably in > TargetAsmBackend. It would be good to have this as a separate patch. This > will allow both COFFWriter and ELFWriter as well as the MachOWriter to > coexist and be selec...

...lvm::MachineModuleInfo* MMI) { } > + > + > /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! > void startFunctionStub(unsigned StubSize, unsigned Alignment = > 1) { > assert(0 && "JIT specific function called!"); > Index: lib/CodeGen/MachOWriter.cpp > =================================================================== > --- lib/CodeGen/MachOWriter.cpp (revision 44794) > +++ lib/CodeGen/MachOWriter.cpp (working copy) > @@ -125,6 +125,20 @@ > return MBBLocations[MBB->getNumber()]; > } > > + virtual...

...{ } >> + >> + >> /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! >> void startFunctionStub(unsigned StubSize, unsigned Alignment = >> 1) { >> assert(0 && "JIT specific function called!"); >> Index: lib/CodeGen/MachOWriter.cpp >> =================================================================== >> --- lib/CodeGen/MachOWriter.cpp (revision 44794) >> +++ lib/CodeGen/MachOWriter.cpp (working copy) >> @@ -125,6 +125,20 @@ >> return MBBLocations[MBB->getNumber()]; >>...

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

...es stub functions which would enable dynamic relinking If not, it would be a straightforward, if platform-specific, feature to add. — Gordon [1] http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/ ELFWriter.cpp?view=markup http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/ MachOWriter.cpp?view=markup [2] http://llvm.org/docs/WritingAnLLVMPass.html [3] http://llvm.org/docs/ProgrammersManual.html#coreclasses [4] http://llvm.org/docs/LangRef.html [5] http://llvm.org/docs/BitCodeFormat.html [6] http://llvm.org/docs/CodeGenerator.html [7] watch this space, currently under rap...

Thanks John. I had passed over ExecutionEngine as it looked like it offered a JIT. Maybe there's more to it than meets the (hasty) eye though. I'm interested in getting a native image. Ultimately, I'd like to do things like emitting Objective-C IMPs and building Objective-C classes around them. However, I'm going one step at a time (there's probably much to learn