similar to: macho-dump deprecation/removal plan

Hi All, I see that llvm-readobj displays information similar to GNU readelf does except DWARF data. I also see llvm-dwarfdump dumps all DWARF data in user readable format. Is there a plan for readobj to incorporate similar options? This will make readobj more feature complete for reading objects similar to readelf. If this is not the plan, will llvm-dwarfdump be a tool that regular user

Hello! Does LLVM provide tools for working with object files? I'm particularly interested in strip and elfcopy tools. Are they a thing? Can they be implemented? Or maybe they are already implemented under different names that I don't know about? I suppose that with LLD there was a lot of code written for working with ELF, COFF and MachO, so it would be relatively easy to implement

Has it ever been considered to prefix executables like opt, bugpoint, obj2yaml, yaml2obj and macho-dump with llvm-? Especially things like 'opt' are too generic of a name and very likely to clash with existing stuff in $PATH.

Hi, Thanks for your patch, Huang. It looks good to me. Just one comment: can you write a testcase, similar to the others used for linker script testing, with your example? Alternatively, you can modify lld/test/elf/linkerscript/sections-with-wildcards.test to test your case. This will make your patch complete and ready for commit, and will ensure we do not regress on this bug if this code is ever

A test I added in r317607 is passing almost everywhere, except for llvm-clang-x86_64-expensive-checks-win. Other Windows bots are happy. http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/6013 The test runs 'sed' on a file to generate variations of the input assembler source for Linux and Darwin. I have to say it looks like 'sed' is being the

On Fri, Jan 15, 2016 at 2:15 PM, Carsten Mattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Has it ever been considered to prefix executables like opt, bugpoint, > obj2yaml, yaml2obj and macho-dump with llvm-? > FYI, macho-dump doesn't exist anymore. That said, I understand the concerns for binutils equivalent (and maybe opt), but I don't think it's too much a

I filed this bug today: https://bugs.llvm.org/show_bug.cgi?id=32376 I understand that the Mach-O linker is not under active development, but there must be some way to work around this bug. Does anyone have a clue? This trivial IR file gives "dyld: lazy symbol binding failed: bad lazy bind info" at runtime when linked with: lld -flavor darwin -demangle -dynamic -arch x86_64

On Mon, Mar 16, 2015 at 1:54 AM, Davide Italiano <davide at freebsd.org> wrote: > > Shankar's parallel for per-se didn't introduce any performance benefit > (or regression). > If the change I propose is safe, I would like to see Shankar's change > in (and this on top of it). > I have other related changes coming next, but I would like to tackle > them one at

Hi, I would like to propose, based on a previous discussion on llvm-dev, the following change. https://reviews.llvm.org/D56337 The main motivation for annotating member functions of ADT clases with LLVM_ALWAYS_INLINE was that of speeding up `check-llvm` at `-O0`. Turns out this significantly degrades the debuggability of fundamental classes in llvm itself, e.g. StringRef or SmallVector. After

I'm not entirely sure whether this is worth an RFC, but, just in case. On bugzilla Eli pointed out we currently match a specific sequence of instructions to cls ( https://reviews.llvm.org/rL206079), and given how fragile this is, it could be better to just introduce an intrinsic for it (and presumably, teach peephole optimizations to lower a sequence to that intrinsic). I wonder what folks are

On Tue, Oct 3, 2017 at 12:08 PM, Davide Italiano <davide at freebsd.org> wrote: > On Tue, Oct 3, 2017 at 11:57 AM, Graham Yiu via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hello, >> >> I recently noticed that the new pass manager was not enabled at regular/thin >> LTO link step even if '-fexperimental-new-pass-manager' was specified in the

On Mon, Mar 16, 2015 at 11:00 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, Mar 16, 2015 at 10:52 PM, Davide Italiano <davide at freebsd.org> > wrote: >> >> On Mon, Mar 16, 2015 at 1:54 AM, Davide Italiano <davide at freebsd.org> >> wrote: >> > >> > Shankar's parallel for per-se didn't introduce any

OK. Let's try a specific example: At least for ELF files, GNU objdump prints operand values in hex. AFAIK, hex is not just the default, but the only choice. On the other hand, llvm-objdump prints operand values in decimal and ignores the --print-imm-hex option for ELF. How about a patch to print operands in hex for ELF? Good place to start? On Mon, Dec 1, 2014 at 5:49 PM, Kevin Enderby

On Mon, Nov 7, 2016 at 5:53 PM, Davide Italiano <davide at freebsd.org> wrote: > On Mon, Nov 7, 2016 at 4:43 PM, Kostya Serebryany via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> The asan bootstrap bot is unhappy with lld. >> Rui, os someone, please take a look. >> >>

On Tue, Sep 5, 2017 at 12:51 PM, Davide Italiano <davide at freebsd.org> wrote: > > > > On Tue, Sep 5, 2017 at 8:16 AM, Nitish Srivastava via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I am trying to locate the passes run by clang/opt when it is passed the option -O3. Can someone point me where to look at? Eventually, I want to

On Mon, Jun 20, 2016 at 10:06 PM, Davide Italiano <davide at freebsd.org> wrote: > On Sun, Jun 19, 2016 at 11:41 AM, vivek pandya via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hello, > > > > I build FireFox-46.0.1 source with llvm to test interprocedural register > > allocation. > > The build was successful with out any runtime faliures,

While playing with sanitizer in a downstream project, I found out this. /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:207:32: error: reference to type 'std::unique_ptr<MCCodeEmitter>' could not bind to an lvalue of type 'llvm::MCCodeEmitter *' UseDwarfDirectory, IP, CE, MAB, ShowInst));

On Dec 17, 2016 7:41 PM, "Sean Silva" <chisophugis at gmail.com> wrote: On Sat, Dec 17, 2016 at 6:32 PM, Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sat, Dec 17, 2016 at 1:35 PM, Davide Italiano <davide at freebsd.org> > wrote: > [...] > > > I don't have an infrastructure to measure the runtime performance > >

Thank you. I went ahead with a speculative fix in r331568. I'm not familiar _at all_ with the tool, so, although the fix was straightforward, another pair of eyes from somebody familiar with the tool would be appreciated. On Fri, May 4, 2018 at 5:10 PM, George Karpenkov <ekarpenkov at apple.com> wrote: > It worked in August. > Last time I’ve asked (again, in August) someone did

Davide Italiano <davide.italiano at gmail.com> writes: >> I couldn't find any support for this on FreeBSD. >> > > AFAIK FreeBSD supports some variant of /proc that should map Linux > (although the mapping isn't 1:1). > Does it lack support for this? Thanks for looking into this, BTW! O_TMPFILE is the main thing that seems to be missing. Cheers, Rafael