similar to: [LLVMdev] how to emit machine code to custom MCStreamer

On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > New patch taking Eli's comments into account. Comments inline. If you have commit access, I'd fire away. If not, I can. diff --git include/llvm/MC/MCAssembler.h include/llvm/MC/MCAssembler.h index 07ca070..afff96e 100644 --- include/llvm/MC/MCAssembler.h +++ include/llvm/MC/MCAssembler.h

On Mar 27, 2010, at 1:50 PM, Peter Shugalev wrote: > Chris Lattner wrote: >> On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: >> >>>>> New method of emitting object code is ok for me. But it is still >>>>> experimental, isn't it? >>>> Yes. >>> Thank you for answers! >>> >>> Now there is a way to implement

New patch. Thanks for all of your comments ! > Comments inline. If you have commit access, I'd fire away. If not, I can. I don't have commit access, if you find it ok, please commit it. :) Olivier. On Wed, Jul 21, 2010 at 6:56 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant > <meurant.olivier at gmail.com>

Chris Lattner wrote: > On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: > >>>> New method of emitting object code is ok for me. But it is still >>>> experimental, isn't it? >>> Yes. >> Thank you for answers! >> >> Now there is a way to implement what I'd like to. But it would be MUCH >> better if

I am creating an ExecutionEngine using the LLVMCreateExecutionEngineForModule function from the C API. I am get a set fault with the following backtrace. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000120 0x0000000107c06643 in llvm::LLVMTargetMachine::addCommonCodeGenPasses () (gdb) bt #0 0x0000000107c06643 in

On Tue, Nov 15, 2011 at 11:06 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote: > >> Jim, >> >> Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. >> >> The issue I was having was

On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: >>> >>> New method of emitting object code is ok for me. But it is still >>> experimental, isn't it? >> >> Yes. > > Thank you for answers! > > Now there is a way to implement what I'd like to. But it would be MUCH > better if LLVMTargetMachine::addPassesToEmitFile could take

Hi Jack, I'm not 100% up on how MIPS represents jump tables, so take with a grain of salt and all that. Normally how this stuff works is that the streamer will create Fixups (MCDataFragment::addFixup()) for anything that might require a relocation. That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for

Chris Lattner wrote: > On Mar 27, 2010, at 11:56 AM, Peter Shugalev wrote: > >>>> What exactly is expected to be coming? Will it be the same way MachO is >>>> currently implemented but with some flexibility to supply my own class >>>> to do actual object output? Or just a return of old ObjectCodeEmitter? >>> We're integrating a full assembler

On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote: > Jim, > > Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. > > The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer

Well Jim, that may just be my problem. As background I am working on the outer reaches of llvm for the direct object output for Mips. Part of what I am to do is instruct the folks working closer to the backend what I am getting that is incorrect. My first reaction is to assume that I am being fed things the correct way and that I am not handling it correctly. I feed the compiler a source file

Dear David, Dumb question: Would it be easier to write an LLVM tool that took the large IR file and divided it into several smaller IR files that could then be code-generated separately? -- John T. David Greene wrote: > We process very large programs and it is not unusual for the IR for some > compilation unit to exceed system memory. With some hacking in LLVM 2.5 > I was able to

Jim, Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer for a specific fixup. One of the issues I hit initially with llvm is that

On Feb 24, 2011, at 8:14 AM, David A. Greene wrote: > Chris Lattner <clattner at apple.com> writes: > >>> class CodeGenOpt { >>> ... >>> public >>> getOptLevel() ...; >>> getFPLevel() ...; >>> getMemLevel() ...; >>> }; >>> >>> Does this sound reasonable? >> >> I don't think that this is

We process very large programs and it is not unusual for the IR for some compilation unit to exceed system memory. With some hacking in LLVM 2.5 I was able to coax LLVM to generate asm for each functioin as it was processed and then completely forget about it (i.e. delete it) and move on to the next function. This required a bit of hackery. I had to create two pass managers, one for the module

I need to create a subclass that derives from MCELFStreamer. We use MCELFStreamer for direct object generation and need to override a virtual method in the base class MCStreamer::EmitGPRel32Value(). I have been having trouble creating the subclass due to #include issues. I can't seem to get it right at the lib/target/<my target>/MCTargetDesc level. My first thought is always that I am

Hi Jack, Can you elaborate a bit on what you're trying to do? Relocations are handled by the ObjectWriter interfaces, not by the streamer. The <ObjectFormat>Streamer classes aren't intended to be subclassed by targets. -Jim On Nov 14, 2011, at 5:50 PM, Carter, Jack wrote: > I need to create a subclass that derives from MCELFStreamer. > > We use MCELFStreamer for direct

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

> 1. What is the preferred method in MC to jump back to a prior section > already defined? (Or is this not supported?) SetSection in the MCStreamer if you really want to change the current section, but maybe all that you need is to setSection in the Symbol? Similar to what is done in MCELFStreamer::EmitCommonSymbol if the binding is local. > 2. It looks like the "correct" way

On May 18, 2010, at 8:23 AM, Daniel Dunbar wrote: > You mention some potential issues on ARM, should we sort those out > before we enable it in Clang? It's somewhat more convenient to have > things be consistent. Sure, I'll be testing some ARM code today. There is also Evan's new REG_SEQUENCE instruction to verify. > I propose that at some point you just replace the old