similar to: RFC: Add a preprocessor to yaml2obj (and other YAML tools)

?The idea itself is indeed good. Regarding to escaping: I think we should have it. Imagine the following example (I've took it from D73828). --- !ELF FileHeader: Class: ELFCLASS[[BITS]] Data: ELFDATA2LSB Type: ET_EXEC Machine: EM_386 # RUN: yaml2obj %s --docnum=4 -D BITS=32 -o %t-32bit.o # RUN: yaml2obj %s --docnum=4 -D BITS=64 -o %t-64bit.o Without escaping it would

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

On 31/03/2020 18:29, Adrian Prantl via llvm-dev wrote: > It's great to see someone interested in improving yaml2obj! > > As far as I'm concerned, the main problem with yam2obj for DWARF testcases is that at the moment, it is both too high-level and too low-level at the same time. For writing debug info testcases, yaml2obj at the moment does not add anything on top of assembler.

Also, why does it say yaml2py?: yaml2obj takes a YAML description of an object file and converts it to a binary file. $ yaml2py input-file .. program:: yaml2py --Sean Silva On Thu, Sep 20, 2012 at 4:59 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Wed, Sep 19, 2012 at 8:25 PM, Sean Silva <silvas at purdue.edu> wrote: >> Sphinx warns that yaml2obj

Hi, As far as I understand now it is impossible to generate ELF object file with relocation sections using yaml2obj tool. I plan to support ELF relocations in the yaml2obj. Does anybody work on it already or plan to start this task soon? -- Simon Atanasyan

Hi there, I'm proposing for the GSoC project: Add DWARF support to yaml2obj[1]. I've uploaded my proposal. If you have any suggestion or ideas, feel free to leave a comment[2]. Thanks! ------ [1] https://llvm.org/OpenProjects.html#llvm_dwarf_yaml2obj [2] https://docs.google.com/document/d/1miCuMQEX8WZ9_hWXWQtOYTA4JAK-yDnPV9vyO_d5vzE/edit?usp=sharing -- Best Regards, Xing

On Thu, Sep 20, 2012 at 7:34 PM, Sean Silva <silvas at purdue.edu> wrote: > Also, why does it say yaml2py?: > > yaml2obj takes a YAML description of an object file and converts it to a binary > file. > > $ yaml2py input-file > > .. program:: yaml2py > > --Sean Silva > Oops. Well, yaml kinda looks like Python... Feel free to fix that. - Michael Spencer

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

Sphinx warns that yaml2obj isn't included into any toctree. Where is a logical place to link this? --Sean Silva

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

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 folks, I am going to implement DWARF support for yaml2obj. I really appreciate it that many of you have given me a lot of useful comments and suggestions in the previous thread [1]. I've had some offline discussions with James and done some updates to the previous proposal. This proposal addresses the issue of properly describing the DWARF sections in YAML both at a high level and at a

On Wed, Sep 19, 2012 at 8:25 PM, Sean Silva <silvas at purdue.edu> wrote: > Sphinx warns that yaml2obj isn't included into any toctree. Where is a > logical place to link this? > > --Sean Silva No idea, which is why it's not linked :P. Add it anywhere you feel makes sense. - Michael Spencer

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 atanasyan.com> wrote: >> As far as I understand now it is impossible to generate ELF object >> file with relocation sections using yaml2obj tool. I plan to support >> ELF relocations in the yaml2obj. Does anybody work

> 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 usual suspects as FYI > > On Tue, Mar 31, 2020 at 10:36 AM Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > For me personally, the ability to write/edit syntactically

I believe the compiler will generate a .debug_ranges section if you use -ffunction-sections, since the addresses of sections will be non-contiguous. From there, you should be able to edit the .debug_ranges assembly as needed (replace references to symbols with 0s in the .debug_ranges content) to get the exact behaviour you want (I'm assuming you don't want to have to hand-edit a

On 5/21/20, Adrian Prantl <aprantl at apple.com> wrote: > I think the example looks like it would be really useful for many categories > of testcases! > Will it still be possible to manually specify the .debug_abbrev section when > this is desired after you are done? Yes, I think it works. There are two ways to edit the .debug_abbrev section. i) Edit the "Attr:" and

I just got a Diffusion notification about a change of mine being reverted by Fangrui, but I'm not sure that's actually what happened and am confused and concerned. My commit was "[DebugInfo] Allow spill slots in call site parameter descriptions", and it appears in the history under two hashes: 1ee84e and 67c416. The first commit contains the actual change. The second touches

(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

On 25/06/2019 11:24, James Henderson via llvm-dev wrote: > Hi Alex, > > Would you recommend that I do what is done in > unittest/ObjectYAML/MinidumpYAMLTest.cpp which just uses a string > inside the source file, or use an Inputs directory? Both are not > great, as you point out about using an Inputs directory > > > I'd be inclined to go with the