similar to: Could LLVM org add LLVM-objcopy into release per-build binaries?

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

Hi Fi $ rpm --query --file /usr/bin/objcopy binutils-2.25.1-9.fc24.x86_64 $ cd syslinux-7cd1ed6/ $ make bios ... make[3]: Leaving directory '/tmp/syslinux-7cd1ed6/bios/gpxe' make[2]: Leaving directory '/tmp/syslinux-7cd1ed6/bios' make[1]: Leaving directory '/tmp/syslinux-7cd1ed6' $ file bios/core/*.bin bios/core/isolinux.bin: data bios/core/isolinux-debug.bin:

Hey everyone! Objcopy is a powerful tool that allows one to modify object files in various manners, for example, modify symbols / symbol tables or copy / remove particular parts of a binary. It also serves as a basis for the strip tool. Currently, llvm-objcopy only supports ELF files while binutils' objcopy can handle Mach-O files as well. Besides extending the existing tool to support Mach-O

That's something I want to do as well for several reasons. That's an orthogonal issue however. On Tue, Oct 2, 2018, 10:21 AM Eric Christopher <echristo at gmail.com> wrote: > I'd give some consideration to moving the objcopy support itself into a > library inside llvm (possibly lib/Object as that makes the most sense) and > then the tool is just a thin wrapper on top

Hi, I am still struggling with my optimized/speedup build of llvm-toolchain v3.8.1. Here: Enable LTO, PGO, optimized-TableGen, split-DWARF and build with GNU/gold and LLVMgold-plugin. The objcopy (binutils v2.22) here on Ubuntu/precise AMD64 does not support '--extract-dwo'. My build fails with... /usr/bin/objcopy: unrecognized option '--extract-dwo'. Now, I did a full build of

objcopy needs "output-target" and "binary-architecture" parameters which makes it necessary to keep a list of known architectures. The bin2s.pl script generates input for the GNU assembler which should produce an object file that is equivalent to that produced by objcopy. I have successfully tested the change on an amd64 Debian/unstable system. --- helper/Makefile.am |

Hi, I'm going to implement Mach-O support in llvm-objcopy. Before working on this, I'd like to hear your thoughts how llvm-objcopy should handle Mach-O section names. By convention, Mach-O section names are denoted by "<segment name>,<section name>". However, GNU objcopy renames them in the following rule [1]: - If the section name is well-known, rename it to an

Hi Zach! I've been thinking a bit about this for a while now and I'm still of two opinions: On Wed, Mar 7, 2018 at 9:21 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Currently llvm-objcopy only supports ELF files, and most of it's command > line flags are ELF / DWARF specific that don't make any sense on COFF > files. So a useful set of

Commit-ID: 908fca5066fa8e8934df21cbde84b8eccab8a5c9 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=908fca5066fa8e8934df21cbde84b8eccab8a5c9 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sat, 19 Jan 2019 23:19:38 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sun, 20 Jan 2019 00:14:40 +0000 [klibc] Kbuild: Add option to

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

Currently llvm-objcopy only supports ELF files, and most of it's command line flags are ELF / DWARF specific that don't make any sense on COFF files. So a useful set of options for COFF would be largely disjoint, with maybe 1-2 overlapping options. What would be the best way to add this in llvm-objcopy? I can think of 3 options: 1) Re-write the existing CLI of llvm-objcopy to use

Hey everyone, Sorry to jump in on this so late. My two cents is that it should remain GNU objoppy compatible most likely. It was always vaguely a desire to have command line compatibility but it has turned out over time that this is actually a crucial feature and should be one of the top priorities. You can't just go into a giant build system and swap out all the uses of GNU objcopy with

Hi, It's not clear to me what you mean by CLI "subcommands". Would you mind giving a brief example? Up to now, we've been trying to keep llvm-objcopy as close as possible to GNU objcopy, to make transitioning between them easier (I'm thinking in particular things like DWO generation). There are a small number of edge cases/unusual behaviours that we have chosen not to

On Wed, Mar 7, 2018 at 9:56 AM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Zach! > > I've been thinking a bit about this for a while now and I'm still of two > opinions: > > On Wed, Mar 7, 2018 at 9:21 AM Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Currently llvm-objcopy only supports ELF

> On May 23, 2019, at 2:05 AM, James Henderson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I discussed this with Seiya off the mailing list yesterday, and this was the suggestion we came up with, on the basis that GNU objcopy has support for the renaming for GDB support, but it might be confusing to people who are new to the system, so we provide a more expected output

Hi LLVM developers, As PR35281 mentioned: $ llvm-objcopy -O binary llvm-cortex-m7.elf llvm-cortex-m7.bin llvm-objcopy: 'llvm-cortex-m7.elf': The file was not recognized as a valid object file. if (ELFObjectFile<ELF64LE> *o = dyn_cast<ELFObjectFile<ELF64LE>>(&Binary)) https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-objcopy/llvm-objcopy.cpp#L200

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

GEN usr/klibc/syscalls/SYSCALLS.i GEN usr/klibc/syscalls/syscalls.nrs GEN usr/klibc/syscalls/typesize.c KLIBCCC usr/klibc/syscalls/typesize.o OBJCOPY usr/klibc/syscalls/typesize.bin GEN usr/klibc/syscalls/syscalls.mk GEN usr/klibc/syscalls/SYSCALLS.i GEN usr/klibc/syscalls/syscalls.nrs GEN usr/klibc/syscalls/typesize.c KLIBCCC

Hi Jake, About a year ago in commit 5049c3422d26b2b68877307c41b35d7e6aae3235, you attempted to solve a race in llvm-objcopy. What was the race? I ask because unless "last change wins" is the result you want, then the race isn't solved. The problem is that `sys::fs::rename` is just a thin wrapper around POSIX semantics, and replacing an existing file is not an error. Dave