similar to: Consistently prefix executables

Dear llvm developpers, I followed the tutorial to build llvm and clang provided here: https://clang.llvm.org/get_started.html The sources are in sync with subversion repository, and I ended up with more than 30GB of binaries in llvm/bin as shown at the end of this message. I assume I did something wrong, but I did not find any entry in the doc that helps me understand how to reduce the size of

On Fri, Apr 27, 2018 at 6:21 PM, Manuel Yguel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Dear llvm developpers, > I followed the tutorial to build llvm and clang provided here: > https://clang.llvm.org/get_started.html > > The sources are in sync with subversion repository, and I ended up with more > than 30GB of binaries in llvm/bin as shown at the end of this

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.

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

Let's suppose that MCLinker folks are here already - I am a committer of this project :). Maybe I did not formulate my suggestion correctly. When I offer to "install" the yaml2obj and obj2yaml utilities I mean result of the "make install" command only. I do not suggest to include this utilities into any distributed binary packages. To be clear I attached the patch with

This patch adds a tool called 'obj2yaml', which takes an object file, and produces a YAML representation of the file. This is a companion tool to Michael Spencer's proposed "yaml2obj" tool. This tool processes only COFF files; the plan is to enhance it to handle other object formats, as well as object archives. The primary uses for this tool is expected to be: 1) Debugging

Hello all, yesterday I sent an email <http://lists.llvm.org/pipermail/lldb-dev/2019-March/014811.html> to lldb-dev proposing a new tool in lldb for yamlization of minidump files. It's been suggested to me that instead of a new tool it may be better to add support for that format to obj2yaml instead. Hence, this email. :) As I expect most people are unfamiliar with this format, I'm

> I wonder why you want to add the new feature to yaml2obj. Maybe, explaining your motivation would help others understand your problem. Thanks for the cue! I am using yaml2obj to generate stub dynamic libraries. On Wed, Nov 1, 2017 at 11:29 AM, Rui Ueyama <ruiu at google.com> wrote: > I don't have a strong opinion on this. yaml2obj was there when I joined to > the project,

I'm seeing the following fail on Linux x86-64, for the last couple weeks at least. This is from 'ninja check-all'. -David FAIL: lld :: wasm/function-index.test (1941 of 1955) ******************** TEST 'lld :: wasm/function-index.test' FAILED ******************** Script: -- : 'RUN: at line 1'; /build/x86_64/bin/llc -filetype=obj

Nothing wrong with going ahead with a temporary measure if the temporary measure is reasonable (besides the discussion if checking in binary files is desirable). Even if you plan to add a test written in YAML, it's better to check in a binary at least for now than checking it in without any tests. On Mon, Apr 20, 2015 at 7:59 AM, Shankar Easwaram <shankarke at gmail.com> wrote: > I

So, I've written a tool called "obj2yaml". It takes an object file (currently just COFF), and dumps out a textual representation. Micheal Spencer has written a companion tool (not yet landed) called "yaml2obj". The primary use for these tools is for generating test cases for lld, though they are general purpose tools, and can be used to generate test cases (or debug) other

Hi All, Following up on https://lists.llvm.org/pipermail/llvm-dev/2020-July/143512.html, and https://reviews.llvm.org/D85408, we would like to consider a design which allows external tools to read the structured contents of the .bb_addr_map section with library calls into an LLVM library. At the same time, we need to have tools/obj2yaml tests in place for bb_addr_map. So it sounds like the

Now the yaml2obj and obj2yaml utilities used in LLVM and LLD projects tests only and not installed by the "make install" command. I think they might be also useful in third-party projects like MCLinker. I suggest to move these utilities into the "tools" category and install them together with other LLVM tools. Any objections or comments? -- Simon Atanasyan

I cannot reproduce this error, but this could be real. David, is this reproducible every time or is this flaky? On Mon, Jan 7, 2019 at 5:03 PM Heejin Ahn via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello David, > > I use x86_64 and it works on my machine. I also can't find this error on > LLVM buildbot page. I'd appreciate if you help me reproduce the problem.

Interesting. If it is generating yaml files that can't be decoded, then definitely sounds like a bug. If you can provide a reduced test case we can try to fix it, but admittedly it can often take some effort to generate a reduced test case. The best way is to use creduce. Use cl or clang-cl and write the pre-processed output to a file, then run creduce on that file with a test that

dumpbin has some clues. I ran dumpbin /all on both object files and diffed the results. In the good object file, Section #2 (.data) has File Pointer to Raw Data = 208, but in the bad file Section #2 (.data) has File Pointer to Raw Data = 0. Also, Section #3 (.bss) in the good file has Size of Raw Data = 4, but in the bad file Section #3 (.bss) has Size of Raw Data = 0. On Fri, Jan 26, 2018 at

On Wed, Apr 2, 2014 at 2:27 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Wed, Apr 2, 2014 at 10:54 AM, Simon Atanasyan <simon at atanasyan.com> > wrote: > > Hi, > > > > On Wed, Apr 2, 2014 at 1:03 AM, Michael Spencer <bigcheesegs at gmail.com> > wrote: > >> On Mon, Mar 31, 2014 at 10:54 AM, Simon Atanasyan <simon at

Hi, I'm playing around with LLVM and stumbled upon this issue while while performing "make install". The build itself was successful. I'm using the latest git version. #make install -- Installing: /home/alesko/llvm-install/bin/llvm-mc -- Installing: /home/alesko/llvm-install/bin/sancov -- Installing: /home/alesko/llvm-install/bin/opt -- Installing:

I'm adding support for elf dynamic symbols in yaml2obj/obj2yaml. I'm seeking opinions about how to model dynamic symbols (and symbols in general) in the yaml structure. Currently, symbols in elf are represented by a top level `Symbols` key, within which symbols are grouped by binding type (Global, Weak, Local). The simplest thing to do would be to mirror this structure to a DynamicSymbols

James, Thanks for the detailed response. Please see my thoughts inline. On Thu, Sep 17, 2020 at 12:33 AM James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > Hi Rahman, > > Traditionally, the ability to read sections is a feature added to > llvm-readobj/llvm-readelf. For some sections, it delegates to methods in > places like the Object library and BinaryFormat, but