similar to: AArch64 tests failing

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

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 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 01.09.2020 06:27, David Blaikie wrote: > A quick note: The feature as currently proposed sounds like it's an > exact match for 'dwz'? Is there any benefit to this over the existing > dwz project? Is it different in some ways I'm not aware of? (I haven't > actually used dwz, so I might have some mistaken ideas about how it > should work) > > If

On 01.09.2020 20:07, David Blaikie wrote: > Fair enough - thanks for clarifying the differences! (I'd still lean a > bit towards this being dwz-esque, as you say "an extension of classic dwz" I doubt a little about "llvm-dwz" since it might confuse people who would expect exactly the same behavior. But if we think of it as "an extension of classic dwz" and

On 02.09.2020 21:44, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 01.09.2020 20:07, David Blaikie wrote: >> Fair enough - thanks for clarifying the differences! (I'd still >> lean a bit towards this being dwz-esque, as you say "an

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 03.09.2020 01:36, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 3:26 PM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 02.09.2020 21:44, David Blaikie wrote: >> >> >> On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com >> <mailto:avl.lapshin at gmail.com>>

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

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

Every case is different, but yes, as I said - I would like to take a closer look at the problem again, it might 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.

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 for the tool

Hello Tobias, I think that looks reasonable to me, I think it will be down to the llvm-objcopy team whether they want to make .ARM.attributes a special case or not. The best way to find out is to submit a patch, citing the problems with old versions of libc, I'd expect that you'll need to add a test case for the patch to be accepted. To do that it is probably best to look at the existing

Jordan, I have sent the patch via Phabricator: https://reviews.llvm.org/D69188 Let me know if I got it right. -- Tobias On Thu, Oct 17, 2019 at 7:12 PM Jordan Rupprecht <rupprecht at google.com> wrote: > > Tobias, > I don't have much experience with ARM, but from your report and Peter's explanation of why LLD does it, I agree we should be consistent with LLD and keep the

Hello Rui, Thanks for your reply. I tried with the keep-section argument and that made the shared library work. Should these sections be kept around by default maybe? -- Tobias On Thu, Oct 17, 2019 at 11:06 AM Rui Ueyama <ruiu at google.com> wrote: > > One thing I noticed is that llvm-strip seemed to remove a .ARM.attributes section. Can you try --keep-section=.ARM.attributes to

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

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

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

For ignore-undefined-symbols.s, the simplest fix ought to be to have the llvm-mc RUN line take the source from <stdin>: # RUN: llvm-mc –filetype=obj –triple=x86_64-pc-linux %s –o %t.o –g becomes # RUN: llvm-mc –filetype=obj –triple=x86_64-pc-linux < %s –o %t.o –g But in this case, llvm-symbolizer still prints the file as $CWD/<stdin> which seems like its own separate bug. --paulr