similar to: Should lld support binary output ("--oformat binary")?

Hello! Does LLVM provide tools for working with object files? I'm particularly interested in strip and elfcopy tools. Are they a thing? Can they be implemented? Or maybe they are already implemented under different names that I don't know about? I suppose that with LLD there was a lot of code written for working with ELF, COFF and MachO, so it would be relatively easy to implement

One of the issues I reported in using lld as the FreeBSD base system linker is that the base system currently uses ld -r to convert a binary file (device firmware image) into an ELF object: > A tool for loading firmware into a wireless USB device includes a > built-in copy of the firmware image, and the image is converted to an > ELF file using ld -r. The invocation is: ld -b binary -d

Hello, I'm enabling clang LTO to improve code size of Uefi standard (http://www.uefi.org/) firmware (https://github.com/tianocore/edk2), which is mostly C code. My project is in https://github.com/shijunjing/edk2 branch llvm : https://github.com/shijunjing/edk2/tree/llvm. I find my most firmware modules work well after enable LTO, but some X64 modules will not run (e.g. hang with CPU

On Fri, Jun 2, 2017 at 2:34 PM, Ed Maste via llvm-dev < llvm-dev at lists.llvm.org> wrote: > One additional use case for you: converting from a binary to an ELF object > file > ``` > objcopy -I binary -O elf64-x86-64 foo.bin foo.o > ``` > This is sometimes used for embedding binary files for use by drivers and > such. > Yea, unfortunately the command-line you

Fantastic! Thanks for all of the input! I'll be considering all of it going forward. The plan right now is just to worry about ELF executables and nothing else. I'm very sympathetic to the "llvm-objtool" change. If everyone is cool with it I'll change the name in the next CL to "llvm-objtool". To start out I implemented a very basic ELF64LE specific bit of code.

Hi, I stopped into IRC to ask about a problem I've been having using Clang in conjunction with LLD to compile and link for an embedded project on Cortex-M ARM processor. First, I am able to separately compile with a call to clang and link with a call to lld, but I cannot use clang to link using lld using the -fuse-ld=lld flag. I have the output from `clang -v -fuse-ld=lld -target

On 22 August 2018 at 04:27, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > However, if you pass the -emit-relocs option to the linker, lld keeps all > relocations that have already been resolved in an output executable. By > analyzing a relocation table in a resulting executable, you could find all > locations where the ifunc PLT is called. Then, you can

Hey, The following code creates a raw binary (no ELF or PE.. just raw): gcc -nostartfiles -c -o hello.o hello.c ld -o hello1 hello.o --oformat binary You can try the following code out with it: void _start() { while(1); } The resulting raw binary is 5 bytes. Now how do you do this in clang/llvm? Apparently llvm-ld doesn't have a "--oformat binary" option. Anybody know how to

Hi Rui, > but why don't you use lld-link (lld for Windows target) instead of ld.lld (lld for Unix target) to create UEFI applications? I need support both PE/COFF and ELF format tools. I’m also working on the lld-link enabling (clang-cl + lld-link) in both Linux and windows. The ld.lld enabling (clang + ld.lld) is for ELF format native users. E.g.

LLVM already implements its own version of almost all of binutils. The exceptions to this rule are objcopy and strip. This is a proposal to implement an llvm version of objcopy/strip to complete llvm’s binutils. Several projects only use gnu binutils because of objcopy/strip. LLVM itself uses objcopy in fact. Chromium and Fuchsia currently use objcopy as well. If you want to distribute your build

Indeed ld does link it. The reason I am using llvm-ld, is for its unique functionality. I intend to link to object files together (created by cling), and link them with llvm-ld. The main feature that I am currently interested in is the ability to have "inline functions" between two object files. This was basically impossible with gcc. Is there any way to make the raw binary with llvm?

On 2009-12-17 22:08, LiteHacker wrote: > Hey, > > The following code creates a raw binary (no ELF or PE.. just raw): > > gcc -nostartfiles -c -o hello.o hello.c > ld -o hello1 hello.o --oformat binary > > You can try the following code out with it: > > void _start() > { > while(1); > } > > The resulting raw binary is 5 bytes. > It is 2.1M here

Hi Rui, A quick question: Does lld-link only work with clang-cl with windows-msvc option? Can lld-link work with clang with linux-gnu option? Thanks Steven Shi Intel\SSG\FID\Firmware Infrastructure From: Shi, Steven Sent: Tuesday, January 29, 2019 1:32 PM To: 'Rui Ueyama' <ruiu at google.com> Cc: llvm-dev at lists.llvm.org Subject: RE: lld write wrong symbol value in .data

Hey, LLVM has logic to parse ELF and PE binaries using `llvm::object::createBinary`. I tried to search in the codebase to see if there's a possibility to add/remove sections after parsing a binary and re-write the binary to another location. Basically, like what llvm-objcopy does. Can you point me to the right classes to look into, if this is something that LLVM has? Many thanks Joseph

Hi, I would like to propose, based on a previous discussion on llvm-dev, the following change. https://reviews.llvm.org/D56337 The main motivation for annotating member functions of ADT clases with LLVM_ALWAYS_INLINE was that of speeding up `check-llvm` at `-O0`. Turns out this significantly degrades the debuggability of fundamental classes in llvm itself, e.g. StringRef or SmallVector. After

On 2020-08-13, David Blaikie via llvm-dev wrote: >Sounds like the llvm-objcopy source code (llvm/tools/llvm-objcopy) is >probably a good place to start. > >On Thu, Aug 13, 2020 at 8:11 AM Joseph via llvm-dev ><llvm-dev at lists.llvm.org> wrote: >> >> Hey, >> >> LLVM has logic to parse ELF and PE binaries using `llvm::object::createBinary`. I tried to

Hi all, My name is Seiya Nuta. I'm studying for my master's degree in University of Tsukuba and interested in the project named "Improve LLVM binary utilities". I've skimmed through llvm-objcopy/llvm-objdump, commit logs, and Bugzilla to figure out what should I do. I have some questions about the project: - What should I prioritize? I suppose that improving llvm-objcopy

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

On Mon, Mar 16, 2015 at 1:54 AM, Davide Italiano <davide at freebsd.org> wrote: > > Shankar's parallel for per-se didn't introduce any performance benefit > (or regression). > If the change I propose is safe, I would like to see Shankar's change > in (and this on top of it). > I have other related changes coming next, but I would like to tackle > them one at

With the correct list this time. On Wed, Sep 9, 2015 at 6:59 PM, Davide Italiano <davide at freebsd.org> wrote: > Hi, > in the last month I spent some time implementing the missing MachO > specific features in llvm-readobj, and converting all the remaining > tests that used macho-dump to the new format. > llvm-readobj should have all the functionality that macho-dump had. If