search for: createasmbackend

...ource. After doing a little more investigation, I decided to take an approach that seems simpler than yours, as I'm only trying to solve my own problem. It relies on having things lower in the MC layer be able to query MCTargetOptions. This is my plan: Make a path from the callers of Target::createAsmBackend to get MCTargetOptions to the MCELFObjectTargetWriter subclass or some method in the creation chain: <client, e.g. llvm-mc> -> Target::createAsmBackend(..., MCTargetOptions) -> (*MCAsmBackendCtorFn)(..., MCTargetOptions) -> <MCAsmBackend subclass constructor wanting...

...created a JITX86AsmBackend which creates the JITObjectWriter. The function which is registered to create AsmBackend (createX86_32/64AsmBackend) needs to know if it should create a classical (ELF, or Darwin/Macho) AsmBackend or a JIT one. To discriminate, I see 2 possibilities : - Add an argument to createAsmBackend functions (bool IsJIT ?) - Set something specific to the JIT on the target triple. Currently I have a "JIT" string in the environment part of the triple. (i686-pc-linux-gnu becomes i686-pc-linux-JIT). As the target triple is easy to change, this is currently the solution I use. What do yo...

I do have an opinion, but don't have enough time to comment in much depth. The approximate approach I had in mind sounds like what you describe, though, the JITObjectWriter is the core piece, the other pieces probably fall into place as it becomes obvious if they are needed. It should be pretty straightforward to bring up something which works for running code with no external symbols, if you

I am implementing a defined, but currently unimplemented by LLVM, ABI. This ABI differs from an existing ABI in its ELF object format by implementing a subset of an existing ABI, but encoded differently and by setting the e_ident EI_CLASS field. I am trying to use MCTargetOptions::getABIName to set a boolean in the modified subclass of MCELFObjectTargetWriter to indicate which relocation encoding