Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] [RFC] Install yaml2obj and obj2yaml utilities together with other LLVM tools"
2014 Jul 28
2
[LLVMdev] [RFC] Install yaml2obj and obj2yaml utilities together with other LLVM tools
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
2015 Apr 20
4
[LLVMdev] [lld] Linker cannot handle sections with non-unique names
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
2014 Apr 02
4
[LLVMdev] [yaml2obj] ELF relocation support
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
2015 Apr 20
2
[LLVMdev] [lld] Linker cannot handle sections with non-unique names
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
2015 Mar 19
4
[LLVMdev] Final added to parser<bool>
Well, you are an mclinker contributor and Google uses mclinker and now
it's broken as the result of your change.
I still don't see any justification to making a change in a public
interface that is used by other non LLVM projects
to fix some issue with clang warnings. People should be able to derive
from those classes. I can't understand
your reasoning as to why these classes must
2015 Mar 19
2
[LLVMdev] Final added to parser<bool>
One could argue that mclinker is doing something good or not by how it's using this class
but I don't see the need for parser<bool> to be final. That is a subjective opinion that mclinker needs to
be changed.
I think that "final" was added to some of these command line classes to avoid some kind of clang warning.
That seems wrong to me that the tools are dictating
2015 Mar 19
3
[LLVMdev] Final added to parser<bool>
On 03/19/2015 08:55 AM, David Blaikie wrote:
>
>
> On Thu, Mar 19, 2015 at 4:30 AM, Reed Kotler <Reed.Kotler at imgtec.com
> <mailto:Reed.Kotler at imgtec.com>> wrote:
>
> One could argue that mclinker is doing something good or not by
> how it's using this class
> but I don't see the need for parser<bool> to be final. That is a
>
2015 Mar 19
2
[LLVMdev] Final added to parser<bool>
On 03/19/2015 09:24 AM, David Blaikie wrote:
>
>
> On Thu, Mar 19, 2015 at 9:18 AM, Reed Kotler <reed.kotler at imgtec.com
> <mailto:reed.kotler at imgtec.com>> wrote:
>
> Well, you are an mclinker contributor
>
>
> Me personally? Not that I know of.
Sorry. I thought i had seen your name in an mclinker commit.
>
> and Google uses mclinker
>
2015 Mar 19
2
[LLVMdev] Final added to parser<bool>
On 03/19/2015 09:38 AM, David Blaikie wrote:
>
>
> On Thu, Mar 19, 2015 at 9:34 AM, Reed Kotler <reed.kotler at imgtec.com
> <mailto:reed.kotler at imgtec.com>> wrote:
>
> On 03/19/2015 09:24 AM, David Blaikie wrote:
>>
>>
>> On Thu, Mar 19, 2015 at 9:18 AM, Reed Kotler
>> <reed.kotler at imgtec.com <mailto:reed.kotler at
2015 Mar 19
2
[LLVMdev] Final added to parser<bool>
On 03/19/2015 09:57 AM, David Blaikie wrote:
>
>
> On Thu, Mar 19, 2015 at 9:52 AM, Reed Kotler <reed.kotler at imgtec.com
> <mailto:reed.kotler at imgtec.com>> wrote:
>
> On 03/19/2015 09:38 AM, David Blaikie wrote:
>>
>>
>> On Thu, Mar 19, 2015 at 9:34 AM, Reed Kotler
>> <reed.kotler at imgtec.com <mailto:reed.kotler at
2014 Oct 20
2
[LLVMdev] [lld][ELF] obj2yaml vs normalized input files (similar to macho)
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
2015 Mar 19
2
[LLVMdev] Final added to parser<bool>
//===----------------------------------------------------------------------===//
// FalseParser
//===----------------------------------------------------------------------===//
class FalseParser : public parser<bool> {
public:
explicit FalseParser(Option &O) : parser<bool>(O) { }
// parse - Return true on error.
bool parse(cl::Option& O, StringRef ArgName, StringRef
2014 Apr 07
1
[LLVMdev] [yaml2obj] ELF relocation support
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
2014 Mar 31
2
[LLVMdev] [yaml2obj] ELF relocation support
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
2020 Sep 16
2
Making library calls for obj2yaml functionalities
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
2020 Apr 24
2
[yaml2obj] GSoC-20: Add DWARF support to yaml2obj
(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
2020 Sep 18
2
Making library calls for obj2yaml functionalities
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
2019 Mar 06
3
RFC: Adding "minidump" support to obj2yaml
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
2020 Mar 04
5
yaml2obj support for COFF debug directories
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
2015 May 30
1
[LLVMdev] LLD improvement plan
I remember something called MCLinker back in times when LLD was starting.
What happened to this project? Sorry if it's absolutely unrelated to the
topic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150530/92d5233c/attachment.html>