similar to: elf2yaml document structure, for dynamic symbols

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

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

The goal of this proposal is to introduce a new type of YAML section for yaml2obj that allows the population of ELF .dynamic entries via a list of tag and value pairs. These entries are interpreted (and potentially validated) before being written to the .dynamic section. The simplest way to satisfy this requirement is for all dynamic entry values to be numeric values. Unfortunately, this

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

On Mon, Apr 20, 2015 at 1:44 AM, Shankar Easwaran <shankarke at gmail.com> wrote: > Attached patch fixes the issue. Thanks for the quick fix. The patch LGTM if you add a test case. Unfortunately yaml2obj does not support duplicated section names but we can use a binary input file. -- Simon Atanasyan

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

Hi, After looking at the Normalized Readers in mach-o, I feel it would be nice if the Gnu flavor to adopt this design what mach-o did in addition to using obj2yaml. Its so much easier to test in the context of lld with normalized readers, IMO. Opinions ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

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

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

I'm now thinking that there's a bug in either obj2yaml or yaml2obj, because if I run just those two tools on my codebase it generates yaml files that can't be decoded, will try now to not add any section to the obj file in llvm-objcopy to see if I can link with obj files that I rewrite (but without adding symbols or sections). One of the bugs that do annoy me is that the timedatestamp

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

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

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

Spoiler: the following only applies to Windows binary format handling. Potential for extending yaml2obj to support COFF debug directories<https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#debug-directory-image-only> recently came up during a code review<https://reviews.llvm.org/D70606#1873185>. Currently, its COFF

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

(Reviving this thread because a code review reminded me I want to reply here. Sorry for the extremely long turnaround). On 31/03/2020 20:22, Fangrui Song wrote: > On 2020-03-31, Adrian Prantl via llvm-dev wrote: >> >> >>> On Mar 31, 2020, at 10:55 AM, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> +1 to all that & cc'ing a few of the

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

I am willing to take code ownership responsibilities for the following: {include/llvm,lib}/{Object,Support} tools/{ar,nm,objdump,ranlib,size} utils/{kate,KillTheDoctor,obj2yaml,yaml2obj,yaml-bench} - Michael Spencer

Hi all, I was giving some thought as to possible project ideas I could propose for this year’s Google Summer of Code, with regards to the LLVM Binutils. One idea that I had was something discussed at last year’s Euro LLVM developer meeting, namely machine-readable output from the LLVM Binutils. Before I actually start advertising this as an open project, I wanted to ask a few questions:

Hmm, ok. In that case let me try again without my local changes. Maybe they are getting in the way :-/ On Fri, Jan 26, 2018 at 9:51 AM Leonardo Santagada <santagada at gmail.com> wrote: > it is identical to me... wierd. > > On Fri, Jan 26, 2018 at 6:49 PM, Zachary Turner <zturner at google.com> > wrote: > >> (Ignore the fact that my hashes are 8 byte in the