search for: objcopy

...NOT failing on x86-64. These all seem to be caused by segfaults (example backtrace below). Is anyone else seeing this? -David LLVM :: DebugInfo/symbolize-no-debug-str.test LLVM :: tools/gold/X86/comdat.ll LLVM :: tools/gold/X86/visibility.ll LLVM :: tools/llvm-objcopy/ELF/add-section-remove.test LLVM :: tools/llvm-objcopy/ELF/add-section.test LLVM :: tools/llvm-objcopy/ELF/armexidx-link.test LLVM :: tools/llvm-objcopy/ELF/auto-remove-shndx.test LLVM :: tools/llvm-objcopy/ELF/binary-first-seg-offset-zero.test LLVM :: tools/llvm-objcopy/ELF/bin...

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...

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...

> 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 option. I'm not experienced with MachO at all, though, so we'd appreciate any feedback from any MachO users. Generally, Mach-O tools separate th...

Hi all, The following tests fail because my username (csabaraduly) contains "bar" : ******************** FAIL: LLVM :: tools/llvm-objcopy/ELF/regex.test (47099 of 50832) ******************** TEST 'LLVM :: tools/llvm-objcopy/ELF/regex.test' FAILED ******************** Script: -- : 'RUN: at line 1'; /home/csabaraduly/wk/LLVM-git/__build_release_99/bin/yaml2obj /home/csabaraduly/wk/LLVM-git/llvm/test/tools/llvm-objcopy/E...

...ing a patch? :) On Fri, Mar 29, 2019 at 9:53 AM Csaba Raduly via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi all, The following tests fail because my username (csabaraduly) contains "bar" : ******************** FAIL: LLVM :: tools/llvm-objcopy/ELF/regex.test (47099 of 50832) ******************** TEST 'LLVM :: tools/llvm-objcopy/ELF/regex.test' FAILED ******************** Script: -- : 'RUN: at line 1'; /home/csabaraduly/wk/LLVM-git/__build_release_99/bin/yaml2obj /home/csabaraduly/wk/LLVM-git/llvm/test/tools/llvm-objcopy/E...

...ain 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 their llvm-objcopy equivalents. This is the whole reason I'm adding the llvm-strip interface. We know of multiple instances where GNU strip is used in large systems and it's non-trivial to replace every last individual usage of GNU strip with the corresponding llvm-objcopy use. We know...

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 tools...

...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 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 th...

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 support whilst doing this. I guess the obvious question from me is do we n...

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 hand...

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...

Hey everyone! In October/November 2018 I started the implementation of llvm-objcopy for MachO with the long-term plan to build some popular binary-level tools on top of it. That effort stopped at the stage where some boilerplate code for reading/writing MachO files was reviewed & committed to LLVM/tools/llvm-objcopy. Later I started working on llvm-lipo (a drop-in replacing f...

...ght be the case that we don't need this complexity in this particular case, but want to double check. But yeah, in general I agree with you! On Thu, May 9, 2019 at 6:09 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > I think that pretty much hits the nail on the head. The llvm-objcopy code > is for when you need to perform mutations primarily. A common mistake (well > a mistake in my opinion) I see is people wanting a one size fits all > solution when one doesn't exist (or perhaps rather, ELFTypes is as close as > we have). As long as we conclude that kind of mut...

Hi Jake, many thanks, yea, I have very similar feelings / thoughts. After some thinking it seems to me that this discussion/problem which I have brought up is, in fact, more relevant to the tools which really need a robust mutable model of an object file (like objcopy, strip, install_name_tool, etc), but the particular case of "lipo" might be simpler, I need to double check that / will take a closer look again. What I mean - the tool "lipo" manipulates "fat" binaries by extracting, removing, replacing slices (slice = object file for...

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 binutils v2.26.1 and using its binaries. Is it possible to embed a test if objcopy is able to p...

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 options for COFF would be largely disjoint, with > maybe 1-2 overlapping options. What would be the best way to add this in > l...

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 of it. > > -eric > > On Mon, Oct 1, 2018 at 4:12 PM Alexander Shaposhnikov via llvm-dev < > llvm-dev at lists.llvm.org> wrote:...

...DWARFEmitter. The only subclass if this right now that I see is one in dsymutil which ends up emitting everything using an AsmPrinter by eventually emitAppleAccelTable(...) from llvm/include/llvm/CodeGen/AccelTable.h. I spoke briefly with Shoaib on this subject and he suggested adding code to llvm-objcopy. I briefly looked through the code and from what I can tell, llvm-objcopy doesn't seem to have any DWARF abilities other than compressing DWARF sections. If we do add functionality to llvm-objcopy, are we ok pulling in DebugInfoDWARF and the LLVM object model? AFAICT the code for this tools has...

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::createBin...