similar to: llvm-objcopy proposal

On Wed, May 17, 2017 at 1:32 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, May 17, 2017 at 1:11 PM, Petr Hosek <phosek at chromium.org> wrote: > >> The motivation is not only memory savings but also security: >> can-never-be-written is strictly better than RELRO in all cases. The >> biggest win is when .dynamic is the sole reason

On Fri, Jan 11, 2019 at 6:26 AM Martin Storsjö <martin at martin.st> wrote: > Hi, > > The COFF support in llvm-objcopy is in a pretty half-finished state at the > moment. I had hoped to have it mostly usable for the common scenarios by > the time of the branch (the initial patch was sent at the end of > November), but it's still lacking stripping of sections (while

On Tue, 15 Jan 2019, Hans Wennborg wrote: > On Sat, Jan 12, 2019 at 12:49 AM Jordan Rupprecht <rupprecht at google.com> wrote: >> >> >> >> On Fri, Jan 11, 2019 at 6:26 AM Martin Storsjö <martin at martin.st> wrote: >>> >>> Hi, >>> >>> The COFF support in llvm-objcopy is in a pretty half-finished state at the >>>

> > Cool. This then makes your other point about requiring LLVM tools less of > an issue because the out-of-tree builds can use whatever tools you choose. > We just need to make the builtins work so that you don’t need them already > built. With that in mind for an intiial solution before you get to stripping out the cmake stuff so that it can do an out of tree bootstrap. I have

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

I'm seeing a bunch of failures on AArch64 after updating this morning. These are 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 ::

Thanks, I'll look into that. (Though earlier you told me that debug info for types could be extended while walking the IR, so I wouldn't have thought that would have worked.) Peter On Fri, Feb 05, 2016 at 03:52:19PM -0800, David Blaikie wrote: > Will look more closely soon - but I'd really try just writing out type > units to MC as soon as they're done. It should be

On Fri, Jun 2, 2017 at 1:01 PM Sean Silva <chisophugis at gmail.com> wrote: > On Thu, Jun 1, 2017 at 8:47 PM, Petr Hosek via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> This is a followup to the discussion that started in D28791. To provide >> the context, we need a way to provide __dso_handle in Fuchsia. __dso_handle >> symbol is mandated by C++

Hi all, We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and we've found that one of the top consumers of memory is the DWARF emitter in lib/CodeGen/AsmPrinter/Dwarf*. I've been reading the DWARF emitter code and I have a few ideas in mind for how to reduce its memory consumption. One idea I've had is to restructure the emitter so that (for the most part) it

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

Petr Hosek via llvm-dev <llvm-dev at lists.llvm.org> writes: > One of the design principles we're trying to follow is to make everything > read-only, unless it has be writable. The only reason for .dynamic to be > writable is DT_DEBUG which is something we never intend to support. FWIW in > Fuchsia all we need is a read-only .dynamic without emitting DT_DEBUG > altogether,

I suspect mingw is going to be incompatible with Petr’s needs. Adding Nico as he probably does the most cross compiling. I did it a little several weeks ago, just not with libc++, and I don’t remember running into any problems. One thing that’s not clear to me is why the resource compiler is even being invoked at all On Tue, Nov 6, 2018 at 5:46 AM Martin Storsjö via llvm-dev < llvm-dev at

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

Context: In r309526 (with a followup fix in r309529) I implemented the use of DWARF's debug_ranges base address specifier entries to reduce the number of object file relocations needed for debug_ranges*. * in a particular binary internally, an optimized build had a 70% reduction in debug_ranges.reloc, a 16% decrease in total object size (with compressed debug info and fission) Nico noted

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

On Tue, Aug 8, 2017 at 6:56 AM Nico Weber <thakis at chromium.org> wrote: > On Aug 7, 2017 6:58 PM, "David Blaikie" <dblaikie at gmail.com> wrote: > > Context: > > In r309526 (with a followup fix in r309529) I implemented the use of > DWARF's debug_ranges base address specifier entries to reduce the number of > object file relocations needed for

The motivation is not only memory savings but also security: can-never-be-written is strictly better than RELRO in all cases. The biggest win is when .dynamic is the sole reason for having a writable segment at all. The distinction is fairly small for exploitability, but not negligible. LLD already has several command-line options that are not supported by or are different from ld or gold, so

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