similar to: [LLVMdev] [lld][ELF] obj2yaml vs normalized input files (similar to macho)

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

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

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

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

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

On Jul 29, 2013, at 10:09 AM, Shankar Easwaran wrote: > On 7/29/2013 11:24 AM, Nick Kledzik wrote: >> On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >>> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use these options", rather than defining new ELF

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 7/30/2013 5:43 PM, Nick Kledzik wrote: > On Jul 29, 2013, at 10:09 AM, Shankar Easwaran wrote: > >> On 7/29/2013 11:24 AM, Nick Kledzik wrote: >>> On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >>>> Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker

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

Yes, the Group is to represent --start-group,--end-group. So the group here will be contained in the linker Input as a vector of lld::files (foo.a, bar.a). thanks Shankar Easwaran On 9/4/2013 3:59 PM, Rui Ueyama wrote: > The first question is that Group is to represent --start-group/--end-group? > > If I understand your proposal correctly, here's the thing: if file is not > in

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

The --as-needed attribute is preserved and is contained within the ELF FileNode. By lld::files, I am referring to lld::File. Thanks Shankar Easwaran On 9/4/2013 4:10 PM, Rui Ueyama wrote: > On Wed, Sep 4, 2013 at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > >> Yes, the Group is to represent --start-group,--end-group. >> >> So the group here will

On 7/25/2013 3:56 PM, Rui Ueyama wrote: > I think I share the goal with you to make the foundation for better > dead-strip, so thank you for suggesting. I'm not sure if marking a section > as a whole as "safe" or "unsafe" is the best approach, though. Some > comments. > > - If the compiler generated code is always "safe", and if we can >

Hi, We have a whole bunch of readers(we would have some more too), and was thinking if we should have a vector of Readers, and have a function isMyFormat in each of them. Any reader that knows to handle, goes ahead and parses the file. On a side note, we currently use .objtxt as an figure out if the file is a YAML file or not. I have added FIXME's in the code, if we could some kind of

Hi, With the inputGraph now, lld models command line options, input files as nodes in the InputGraph called InputElements. In the current approach, each InputElement is converted to a LinkerInput, which works if all lld deals with individual files. Dealing with ControlNodes (Groups), have a problem with it, on how to model that as a LinkerInput. Joerg/Me were chatting on the IRC about this

Hi Nick, On 9/4/2013 4:04 PM, Nick Kledzik wrote: > I do think we have too many classes. Agree. > I thought InputGraph was going to replace InputFiles. Interesting idea. > It seems link LinkerInput could be merged into FileNode. Agree. > > Originally InputFiles was the abstract interface that he Resolver used to see all the inputs. If InputGraph supported the methods

Hi, It is needed that lld verifies the input to the linker. For example : a x86 ELF file can be given to lld when the target is x86_64. Similiarly with other flavors. I was thinking to have a varargs function in the LinkingContext that would be overridden by each of the LinkingContexts to verify files after being read. The reader would call the varargs function in the LinkingContext and

On Wed, Sep 4, 2013 at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > > Yes, the Group is to represent --start-group,--end-group. > > So the group here will be contained in the linker Input as a vector of > lld::files (foo.a, bar.a). It seems you dropped --as-needed attribute... ? By lld::files, what class are you pointing to, lld::File or lld::InputFiles?