similar to: [lld] supporting binary-to-ELF conversion

As I've mentioned before[1] I've been regularly attempting to build the FreeBSD/amd64 base system with lld, in order to keep track of progress and identify issues on an ongoing basis. As of last November a 'buildword' (i.e., userland build) ran to completion, with several workarounds applied to the FreeBSD base system. However, the result did not actually work. I'm pleased to

One remaining blocking issue for linking FreeBSD with lld is the inability to build the bootloader components. We have a patch[1] in review to address one of the problems by switching to using a linker script instead of GNU ld's -N option. Another issue is that some bootloader components are created by the linker directly as binary objects, using --oformat binary. (Other bootloader components

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.

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

Hi LLVM devs,  I came across an LLD bug in v 10.x where ELF parser / processor is setting .PROGBITS attribute for .heap and .stack sections, which leads to large binaries when we do `llvm-objcopy -o binary` to generate the binary output for armv6m. (e.g. for a 57Kb elf would yield a ~400Mb binary). This in comparison with LLVM 7.x , would produce the correct binary size of 35Kb and the

Hi Andrew, Thanks for the background and context. "In your issue, just to clarify, is the ELF output from LLD also "large", or is it just the output from the llvm-objcopy operating on that ELF that is "large"? Do you have a simple sample to demonstrate this issue?" The ELF size is actually smaller, compared to what was generated from LLVM 7.x. (~900Kb vs

Debuginfo folks, What is your opinion on this proposal? Do we need to work on better DWARFLinker library for now? or Can we start to integrate llvm-dwarfutil as a series of small patches? If it is OK to start integrating of llvm-dwarfutil, Is it OK to move llvm-objcopy implementation into separate library ObjCopy ? Thank you, Alexey. On 01.09.2020 20:18, James Y Knight wrote: > > >

Hi James, Thank you for the comments. >I think we're not terribly far from that ideal, now, for ELF. Maybe only these three things need to be done? -- >  1. Teach lld how to emit a separated debuginfo output file directly, without requiring an objcopy step. >  2. Integrate DWARFLinker into lld. >  3. Create a new tool which takes the separated debuginfo and DWO/DWP files

We're in the process of importing lld into FreeBSD (along with our Clang 3.9 update project). For now I've removed all but the ELF linker[1]. We have no need for COFF and Mach-O, and we have a bespoke build system for all of our contrib code. I didn't bother adding build support for the source files for non-ELF linkers. Is this something that'd be reasonable / desirable to have

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

On 12 September 2016 at 16:23, Rui Ueyama <ruiu at google.com> wrote: > What's the motivation to not build COFF and Mach-O parts? If you don't need > it, you could just leave it. Are you trying to reduce the executable size? It was just easier to remove coff::link() and mach_o::link() from lld.cpp than to add them to our own build infrastructure

Hi,   We propose llvm-dwarfutil - a dsymutil-like tool for ELF.   Any thoughts on this?   Thanks in advance, Alexey. ====================================================================== llvm-dwarfutil(Apndx A) - is a tool that is used for processing debug info(DWARF) located in built binary files to improve debug info quality, reduce debug info size and accelerate debug info processing.

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

On 26.08.2020 10:58, James Henderson wrote: > In principle, this sounds reasonable to me. I don't know enough about > dsymutil's interface to know whether it makes sense to try to make it > multi-format compatible or not. If it doesn't I'm perfectly happy for > a new tool to be added using the DWARFLinker library. > > Some more general thoughts: > 1)

On 26 July 2018 at 15:52, Ed Maste <emaste at freebsd.org> wrote: > On 27 February 2018 at 09:06, Ed Maste <emaste at freebsd.org> wrote: >> >> A number of companies are shipping products based on FreeBSD/arm, on >> v5 and up. As far as I know those using older processors are also >> using older versions of FreeBSD (with a toolchain based on GCC and >>

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

On 26 July 2018 at 18:05, Ed Maste <emaste at freebsd.org> wrote: > On 26 July 2018 at 11:08, Peter Smith <peter.smith at linaro.org> wrote: >> On 26 July 2018 at 15:52, Ed Maste <emaste at freebsd.org> wrote: >>> On 27 February 2018 at 09:06, Ed Maste <emaste at freebsd.org> wrote: >>>> >>>> A number of companies are shipping

Hi, Thanks a lot for your answer. It seems lld is still the best solution, even if it does not work "right out of the box" for us today. We already have a solution for the "objcopy" part (added the required output format to llvm-objdump). The ScriptLayout class seems to be empty for now (on the master branch at least), but we do not need linker scripts today. All that is

Sorry for being late on this thread. I just wanted to say I am strongly on Rui's side on this one. There current design is for lld *not* not be a library and I think that is important. That has saved us a tremendous amount of work for doing library like code and a lot of design for library interfaces. The comparison of old and new ELF code is night and day as far as productivity and

I am looking to create a tool that can add Apple or DWARF5 accelerator tables to fully linked executables that contain DWARF. This will help us benchmark how much accelerator tables can improve the debugging experience as debuggers don't need to manually index all of the debug info during debugging. Looking at how accelerator tables are currently emitted, they seem to be built up as DWARF is