similar to: RFC: Adding "minidump" support to obj2yaml

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

Hello Wine users! I've got a minidump from a ("real") Windows user of our game and would like to extract information from it using winedbg. The information winedbg gives me by default, is this: WineDbg starting on minidump on pid 068c warzone2100.exe was running on #1 Intel ???-0.521 CPU on Windows XP (2600) Register dump: CS:001b SS:0023 DS:0023 ES:0023 FS:003b GS:0000

Thanks James! Thanks for the help. I certainly see your point. > In either case, if you wanted to change the test input, you'd need to rerun CMake again This is unfortunate, I would have hoped I could have CMake create $(wildcard *.yaml) type of output in the make files. But it sounds like this doesn't exist on make alternatives, so this wont work. There is actually a function to get

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

LLVM Weekly - #110, Feb 8th 2016 ================================ If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/110>. Welcome to the one hundred and tenth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

Hi, I've a problem; I've tryed to install wine 0.9.7 on a Mac Computer on Mac OS X System. I've downloaded source files from source-forge.net I have made configuration,and make dependecies and finally I did "make" !...but...at least appears a terrible message: #error unsupported cpu (minidump.c 172.2).... I've tryed this on two different computers: a IBM PowerPC G5