search for: mccodeemitt

...PIC code for RISC-V in the context of Linux. Not sure if anyone is working on this already, any inputs are very welcome. I'm now looking at function calls which in the RISCV backend are represented via two pseudoinstructions RISCV::TAIL and RISCV::CALL. Currently those pseudos are lowered in MCCodeEmitter. They are expanded into AUIPC and JALR instructions and the first one needs a relocation, which for a static reloc model is R_RISCV_CALL but for PIC code should be R_RISCV_CALL_PLT. The problem I find is that at this point it is too late to tell the exact relocation needed: as far as I can tell...

While playing with sanitizer in a downstream project, I found out this. /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:207:32: error: reference to type 'std::unique_ptr<MCCodeEmitter>' could not bind to an lvalue of type 'llvm::MCCodeEmitter *' UseDwarfDirectory, IP, CE, MAB, ShowInst)); ^~ /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:514:66: note: passing argument to p...

...lists.llvm.org> wrote: > > While playing with sanitizer in a downstream project, I found out this. > > /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:207:32: > error: reference to type 'std::unique_ptr<MCCodeEmitter>' could not > bind to an > lvalue of type 'llvm::MCCodeEmitter *' > UseDwarfDirectory, IP, CE, MAB, ShowInst)); > ^~ > /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:514:66: >...

...wrote: >> >> While playing with sanitizer in a downstream project, I found out this. >> >> /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:207:32: >> error: reference to type 'std::unique_ptr<MCCodeEmitter>' could not >> bind to an >> lvalue of type 'llvm::MCCodeEmitter *' >> UseDwarfDirectory, IP, CE, MAB, ShowInst)); >> ^~ >> /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegi...

[apologies for this duplicate post: originally sent to lldb-dev by not paying attention to the address auto-completion] We have a backend for a target that at present only detects some assembler errors when emitting instructions (basically because the platform has configurable properties with dependencies between instructions and it was easier to check for their interaction late than try to

On Tue, 2014-01-14 at 22:59 -0800, Craig Topper wrote: > I started trying to fix this tonight but it's pretty nasty to fix. > I'll try to make another go at it later this week. Much of it seems fixed already; what's left to fix? The segment prefix override? Does that mean we get to fix disassembly of '0x65 0xa4' while we're at it? (Although we can't even

...size of the >> packet be properly accounted for by the MCObjectStreamer if we have to pad >> the packet (mainly for fetch alignment)? > The MC system (including relaxation) is capable of handling instructions with variable length encodings whose size can't be determined until the MCCodeEmitter step. Where could I find more information about how this is handled? TIA -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum

The actual size of even a MC instruction will change during relaxation--we don't choose between 8-bit jumps and wider jumps until relaxation. You can get the actual encoding of an MCInst via MCCodeEmitter, but if you expect relaxation to occur, or particularly if you're testing before register allocation, the size could only be an estimate and shouldn't be trusted for exact size. -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Matthias Br...

...instruction such as ``ADD %EAX, %EBX``, in X86 is actually equivalent to ``%EAX = %EAX + %EBX``. @@ -1578,7 +1578,7 @@ correspond to. The MCInsts that are generated by this are fed into the instruction printer or the encoder. -Finally, at your choosing, you can also implement an subclass of MCCodeEmitter +Finally, at your choosing, you can also implement a subclass of MCCodeEmitter which lowers MCInst's into machine code bytes and relocations. This is important if you want to support direct .o file emission, or would like to implement an assembler for your target. -------------- next part --...

...cted as a leak (example from lib/Target/Sparc/MCTargetDesc/SparcMCTargetDesc.cpp) : static MCStreamer *createMCStreamer(const Target &T, StringRef TT, MCContext &Context, MCAsmBackend &MAB, raw_ostream &OS, MCCodeEmitter *Emitter, const MCSubtargetInfo &STI, bool RelaxAll, bool NoExecStack) { MCStreamer *S = createELFStreamer(Context, MAB, OS, Emitter, RelaxAll, NoExecStack); new SparcTargetELFStreamer(*S); 1...

...to make it when emitting obj file. And when the code & data are mixed, the disassembler will failed to parse the binary properly. For example, if we place a CONSTPOOL_ENTRY in .text section and it will confused the disassembler. I wonder if is possible to emit subsections (of .text section) in *MCCodeEmitter to mix data into code and avoid confusing disassembler, like this [1]? Any Ideas? Thanks. [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-June/032263.html Cheers. Huang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm...

...coding of that > in > > struction as an array of bytes), not the integer descriptor returned by > > I->getOpcode(). > > That's not generally possible. The best you might be able to do would > be to lower each MachineInstr to an MCInst and emit its encoding via > an MCCodeEmitter. But that has quite a few problems: > > + There's virtually no hope before register allocation. You'd > probably get an assertion if you're lucky. > + Many targets don't have really separate "opcode" and "operand" > bytes. Just 32-bit (say) i...

Hi, I am trying to undertand which code in LLVM patches the fixups generated by assembler. Here is what I am doing: I use "llvm-mc" to compile X86 assembly code, like below: $ echo "jmp 5000" | ./bin/llvm-mc -assemble -triple=i386 -show-encoding -x86-asm-syntax=att -output-asm-variant=1 .text jmp 5000 # encoding: [0xeb,A]

...t; Will the size of the > packet be properly accounted for by the MCObjectStreamer if we have to pad > the packet (mainly for fetch alignment)? The MC system (including relaxation) is capable of handling instructions with variable length encodings whose size can't be determined until the MCCodeEmitter step. --Owen

Hi, I have a basic machine function pass in this fashion: bool Foo::runOnMachineFunction(MachineFunction &Fn) { for (auto &BB : Fn) { for (MachineBasicBlock::iterator I = BB.begin(), E = BB.end(); I != E; ++I) { if (I->isPseudo()) continue; // inspect opcode of I here } } } return true; } As the comment suggests I want to inspect the

Hello Owen, > There should already be sufficient support for what you're trying to do. See > MCOperand::CreateInst(). The concept is that you'll build a composite MCInst in > your AsmPrinter::EmitInstruction() method, which uses Inst-type MCOperands to > hold a list of sub-instructions. Then you call AsmStreamer::EmitInstruction() on the > composite MCInst. Thanks for

...b/lib/MC/MCELFStreamer.cpp index 8107005..153ca78 100644 --- a/lib/MC/MCELFStreamer.cpp +++ b/lib/MC/MCELFStreamer.cpp @@ -40,12 +40,14 @@ class MCELFStreamer : public MCObjectStreamer { public: MCELFStreamer(MCContext &Context, MCAsmBackend &TAB, raw_ostream &OS, MCCodeEmitter *Emitter) - : MCObjectStreamer(Context, TAB, OS, Emitter) {} + : MCObjectStreamer(Context, TAB, OS, Emitter), + IsThumb(false), MappingSymbolCounter(0) {} MCELFStreamer(MCContext &Context, MCAsmBackend &TAB, raw_ostream &OS, MCCodeEmitter *Emitter,...

...top-level MCInst (i.e. the entire bundle) is encoded all at once from > the point of view of the target-independent mechanisms. Those mechanisms > use target-specific code that each implementation needs to provide, and > in your code you can handle each bundle as you want. > > Check MCCodeEmitter and how different targets implement it. > > As for the syntax---the parser needs to be able to determine the bundle > boundary. (For example Hexagon uses braces {} to enclose each bundle.) > The way the assembler works is that it constructs an instruction and > passes it to the ass...

...er during Post-RA scheduler. > No. Two reasons that’s not going to work. First, the CodeEmitter runs as the absolute last pass. Nothing will ever come after it, and it assumes that to be true (it’s for the JIT). Second, the CodeEmitter pass is going away entirely sooner rather than later. The MCCodeEmitter takes its place. That requires lowering the instructions to MC, which again happens much later, and is required to happen much later, than the scheduler. -Jim > Sorry for the trouble! > > Thanks, > Jafar J. > > From: Jim Grosbach > Sent: Thursday, May 30, 2013 9:18...

...clude "llvm/MC/MCSection.h" > #include "llvm/MC/MCSymbol.h" > #include "llvm/MC/MCExpr.h" > +#include "llvm/MC/MCValue.h" > +#include "llvm/MC/MCAssembler.h" > +#include "llvm/MC/MCAsmLayout.h" > #include "llvm/MC/MCCodeEmitter.h" > #include "llvm/MC/MCSectionCOFF.h" > +#include "llvm/Target/TargetRegistry.h" > #include "llvm/Target/TargetAsmBackend.h" > +#include "llvm/ADT/StringMap.h" > + > #include "llvm/Support/COFF.h" > #include "l...