similar to: Using an MCStreamer Directly to produce an object file?

Hello Tim, Rafael, Renato and llvmdev, I’m working to get llvm-objdump handle both arm and thumb disassembly from the same object file similarly to how darwin’s otool(1) works. And I’m looking for implementing direction. I spoke to Jim Grosbach about some ideas and he suggested I send out and email about some of the possibilities. Since none of the ones I could think of are pretty he thought

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote: > This is the key question. The LLVM assumption is that these sorts of things > are inferable from the triple. Your observation here that the GNU world’s > notion of triples and LLVM’s need not be the same is a good one. Having a > split and a translation up in clang seems an interesting avenue to explore. >

Hi, I have been trying to use LLVM as a disassembler, thus providing a small part of my decompiler that I am working on. It currently decompiles from X86_64 binary.o -> LLVM IR. It works with a small set of test programs so far, so cannot currently handle large binary programs yet. The problem is with the LLVM "getInstruction()" method. It used to have a PC (program counter)

Hi, My apologies if this appears to be a very trivial question -- I have tried to solve this on my own and I am stuck. Any assistance that could be provided would be immensely appreciated. What is the absolute bare minimum that I need to do to disassemble an array of, say, ARM machine code bytes? Or an array of Thumb machine code bytes? For example, I might have an array of unsigned chars -- how

Hi, I'm embarrassed that I can't figure this out... I have a compiler that outputs my module in either .s assembly format or .obj binary format, either one works just fine. But if I try to output both of them by adding passes, LLVM throws an Assert: void WinCOFFStreamer::EmitLabel(MCSymbol *Symbol) { assert(Symbol->isUndefined() && "Cannot define a symbol

Hi all. I fully understand that the problem is a bit OT for llvmdev, but I'm stuck for two days now and I really need some direct push. To the problem. I have a C++ shared library, that's working with llvm C++ api. Consider a function: static Object llvm_Target_createMCAsmInfo(Object self, Object tripleName) { llvm::Target target = from_ruby<llvm::Target>(self); char const

Hi Aiden, The easiest thing I can do is to point you to the source of the "llvm-mc" tool, which does exactly what you ask in its "-disassemble" mode. The code is rather small, so it should be easy to work out. tools/llvm-mc Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Aidan Steele Sent:

Hi Aiden, The 'C' based interface you could use in is llvm/include/llvm-c/Disassembler.h, which in there is: /** * Disassemble a single instruction using the disassembler context specified in * the parameter DC. The bytes of the instruction are specified in the * parameter Bytes, and contains at least BytesSize number of bytes. The * instruction is at the address specified by the

Hello, My question in 2 words is the following: Is it mandatory to generate host keys on the target host, or can they be generated on another host and transfer to thetarget host ? If my question is not clear here is an example... I need to install host keys on a host server. I imagine the usual way is to launch the following command locally on the host server . # ssh-keygen -t rsa1

Hi Kev and James, Thanks to both of you for responding. I had looked at the otool release published for 10.7.2 (cctools-800), but it seems that it only snuck in after that and by the cctools-809 release! In any case, both that and llvm-mc should be more than adequate! A follow-up question: is the C interface to LLVM a second-class citizen or should I reasonably be able to expect to do everything

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>

Hi Daniel, attached is a patch that pushes most of the object file specific parsing out of AsmParser and down into MachOAsmParser. This was done as a cleanup for the ELF work. I know that you're not happy with this approach, particularly the fact that as we add more object file formats and assembler dialects, it's going to cause a class explosion. But I was hoping that we could use this

Llvm typically doesn't build with RTTI enabled. Perhaps that's what you're running into? Jim On Dec 10, 2012, at 1:27 PM, Vladimir Pouzanov <farcaller at gmail.com> wrote: > Hi all. > > I fully understand that the problem is a bit OT for llvmdev, but I'm stuck for two days now and I really need some direct push. > > To the problem. I have a C++ shared

Hi! I'd like to emit code to a custom MCStreamer instead of e.g. MCELFStreamer. Unfortunately LLVMTargetMachine::addCommonCodeGenPasses is private but I would need it, or even better a method simular to addPassesToEmitFile (e.g. addPassesToEmitCustomMC) taking an MCSreamer would be great. What do you think? -Jochen

On 7 May 2010 08:15, Nathan Jeffords <blunted2night at gmail.com> wrote: > > > On Fri, May 7, 2010 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: >> >> Thanks! Funny, I was just preparing a patch to submit for my changes to >> MCSectionCOFF. My changes look to be fairly

> > > The logic to handle this has to go somewhere, putting it in the MCStreamer > *implementation* that needs it is the most logical place. We also aim to > implement an assembler, it doesn't make sense to duplicate this logic in the > compiler and the assembler parser. > > Assembly language has often been *the* intermediate form for between compilers and object

Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit it. I was just pondering how to deal with the

This is a brain-dump of my thoughts on the MCStreamer interface after several days of digging around trying to get a COFF writer working. All fragments should be associated with a symbol. For assembler components, a unnammed "virtual" symbol can be used when there is no explicit label defined. Section assignment should be the responsiblity of the object imlementing the MCStreamer

I should probably elaborate on why I feel the interface should be as such. It seems to be the common case is compiler outputting to object files. In this case, all fragments are associated with symbols. What section the fragments go into is generally irrelevant to the compiler, except in special cases like global variable constructor/destructor lists and the like. At code generation time, the