similar to: ELF object writing from assembly file

Thanks a lot Tim. I am getting an error which says: "LLVM ERROR: unable to write nop sequence of 0 bytes" Is there any way that I can print out the Obj code (I mean bitstream representation of the assembly code which is going to be placed in the ELF file), before making any ELF file? Cheers, ES On Tue, Oct 13, 2015 at 3:02 PM, Tim Northover <t.p.northover at gmail.com> wrote:

Hi all, I have defined an instruction in the InstFormat.td and InstrInfo.td files. I also wrote a CodeEmitter class for that, and now I have a .inc file after compilation that seems like it might be correct, BUT, I would like to see what will be generated when the assembly code is converted to the binary machine code! Is there any command in TableGen or a test class to do so? Cheers, ES

Dear all, I am trying to write an AsmParser and a CodeEmitter for simple ADD instruction. Here is what I have in the TestGenInstrInfo.td: *extern const MCInstrDesc TestInsts[] = {...{ 23, 3, 1, 0, 0, 0, 0x0ULL, nullptr, nullptr, OperandInfo13, 0, nullptr }, // Inst #23 = ADD8_rr...}* I parse the instruction successfully but I am not sure what I did wrong that the Size (as you can see in

Hi everyone, I am getting into the ARM specific relocation for MC/ELF, and have some questions There are some x86/arm specific relocation values already, before they are lowered down to ELF reloc types (i.e. ARMRelocations.h and X86Relocations.h) As near as I can figure it, the relocation constants in (ARM|X86)Relocations.h are used only in ARMCodeEmitter, and X86CodeEmitter.cpp respectively -

Hi all, A broad goal of many of the LLVM binary tools, such as llvm-objcopy and llvm-objdump is to provide an alternative to the GNU equivalent, and as such, these tools have been developed to be command-line compatible. One tool where this hasn’t been the case up to now is llvm-readobj (aka llvm-readelf). There was some discussion in https://reviews.llvm.org/D33872 about the purpose of

Pinging this thread to see if anyone else has opinions or objections -- if not I plan to go ahead with stepping towards compatibility with readelf vs llvm-readelf in https://reviews.llvm.org/D54124 on Monday. On Tue, Nov 6, 2018 at 9:52 AM Jordan Rupprecht <rupprecht at google.com> wrote: > Hi James, > > I also wanted to work on this discrepancy, but I just sent a patch instead

Hi all, I am experimenting with extending ELF. I want to add a custom ELF section, something similar to a 'SyntheticSection'. However, I'm not able to find documentation / doxygen for LLD code. Are there any existing examples of adding custom ELF sections at link time in LLVM framework? Is it possible? Any pointers? Thanks in advance!Cheers! -------------- next part -------------- An

Hi All, I see that llvm-readobj displays information similar to GNU readelf does except DWARF data. I also see llvm-dwarfdump dumps all DWARF data in user readable format. Is there a plan for readobj to incorporate similar options? This will make readobj more feature complete for reading objects similar to readelf. If this is not the plan, will llvm-dwarfdump be a tool that regular user

Hi ES, From what I understand instruction parsing is divided into two parts: - Parsing an operand list (XXXAsmParser::ParseInstruction) - Turning the operand list into an actual instruction (XXXAsmParser::MatchAndEmitInstruction) The second part does the validation (e.g. how many operands, what kind, etc) while the first part only does the parsing. That's why I think in the first part

Many llvm utilities use cl::ParseCommandLineOptions() (include/Support/CommandLine.h) to parse command line options. The cl library accepts both -long-option and --long-option forms, with the single dash form (-long-option) being more popular. We also have many binary utilities (llvm-objcopy llvm-objdump llvm-readobj llvm-size ...) whose names reflect what they imitate. For compatibility with GNU

Hi all, I was giving some thought as to possible project ideas I could propose for this year’s Google Summer of Code, with regards to the LLVM Binutils. One idea that I had was something discussed at last year’s Euro LLVM developer meeting, namely machine-readable output from the LLVM Binutils. Before I actually start advertising this as an open project, I wanted to ask a few questions:

> Are you proposing to make this the new style across all LLVM utilities? No. Only drop --long-option for GNU binutils replacements (people sometimes call them LLVM binary utilities): llvm-objcopy (D60439), llvm-ar, llvm-size, llvm-nm, etc. llvm-objdump (not sure what to do with mach-o specific dump options), llvm-readelf (not sure what to do with llvm-readobj) On Sat, Apr 20, 2019 at 2:13 AM

Hi, Just realized that ability to generate static object code (e.g. ELF w/o using JIT) is no longer available in 2.7 (at least in release_27 branch). For example > llc -filetype=obj whatever.bc doesn't work in Linux environment anymore (well it wasn't fully implemented before but it worked for simple bytecodes in 2.6). I used to generate code by creating TargetMachine and

On Jul 16, 2009, at 12:53 AM, Aaron Gray wrote: > Chris, > > The basic idea of using templates inconjunction with inlining is for > efficiency. > > 6,500 virtual calls outputting bytes out of 10000 calls, and the > rest 1,750 being words to output 10,000 of code does not entice me > to use virtual calls. I understand that you say that, but I can't bring myself

For binutil compatibility, and in general for any new tools, this sounds reasonable to me. But I'd worry that things like llvm-readobj have existed for a long time and people are used to flags like "-sections", and it may be complicated to change that now. (I guess this RFC is a check to see if this is true for anyone on the mailing list). What happens if you make this change and

Hi David, Thanks for the feedback! I've reverted r258665 until I understand this better. > The linker considers three sources: > - EXPORTS directives in a .def file given to the linker > - The linker's /EXPORT option > - Object files carry a special section, .drectve, which contains additional flags that the linker takes under consideration. __declspec(dllexport) is

On May 30, 2013, at 11:35 AM, Jafar J <pluck90 at hotmail.com> wrote: > Hi Jim, > > The idea of reducing the switching activity between the instructions works by reducing the hamming distance between tow consecutive binary strings across the basic block, or reducing the number of the different bits between two consecutive instructions. This is why I need the exact complete

On Mon, Apr 13, 2020 at 1:16 PM Jon Roelofs via llvm-dev < llvm-dev at lists.llvm.org> wrote: > As an update, after lots of fixes from a number of different people > (thanks everyone!), the current list of false-positives on `ninja > check-llvm` for the more stringent Gotcha A diagnostic is: > > LLVM :: Analysis/CostModel/X86/vselect-cost.ll > LLVM ::

2009/7/16 Chris Lattner <clattner at apple.com> > > On Jul 16, 2009, at 12:53 AM, Aaron Gray wrote: > > Chris, > > The basic idea of using templates inconjunction with inlining is for > efficiency. > > 6,500 virtual calls outputting bytes out of 10000 calls, and the rest 1,750 > being words to output 10,000 of code does not entice me to use virtual >

It's actually a bit weirder than you might think. The CommandLine parser will happily eat as many dashes as you care to write, e.g., `----sections` is the same as `-sections`. On Tue, Apr 16, 2019 at 2:11 AM James Henderson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > As I think I said elsewhere, I find it weird that LLVM tools accept long > arguments with a single dash,