Displaying 20 results from an estimated 10000 matches similar to: "[RFC][binutils] Machine-readable output from Binutils - possible GSOC project?"
2012 Nov 06
10
[LLVMdev] Binutils and LLVM - gathering information
Binutils and LLVM
As part of "owning our own toolchain", various people have expressed an interest and have been working on creating various tools that duplicate the functionality of tools available on other systems.
As a start, I'd like to summarize the current status, and ask people for help updating the list.
List taken from <http://www.gnu.org/software/binutils/>
2013 Oct 17
2
[LLVMdev] llvm-objdump disassembling jmp
In creating a test case for a bug fix in llvm-objdump, I noticed that it differs in its output of pc-relative immediates from objdump:
[secdev:/tmp] s$ cat a.s
main:
jmp .LBL0
.LBL0:
ret
[secdev:/tmp] s$ llvm-mc -filetype=obj a.s > a.o
[secdev:/tmp] s$ objdump -d a.o |tail -n 2
0: eb 00 jmp 2 <main+0x2>
2: c3 retq
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
2013 Oct 17
0
[LLVMdev] llvm-objdump disassembling jmp
On Thu, Oct 17, 2013 at 10:55 AM, Stephen Checkoway <s at pahtak.org> wrote:
> In creating a test case for a bug fix in llvm-objdump, I noticed that it
> differs in its output of pc-relative immediates from objdump:
>
> [secdev:/tmp] s$ cat a.s
> main:
> jmp .LBL0
> .LBL0:
> ret
> [secdev:/tmp] s$ llvm-mc -filetype=obj a.s > a.o
>
2020 Feb 06
2
compatibility with gnu binutils
>
> From: James Henderson via llvm-dev <llvm-dev at lists.llvm.org>
> To: Oliver Stannard <oliver.stannard at linaro.org>
> Cc: LLVM Dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] [RFC] Case insensitive assembly directives for
> all targets
>
> +1 to all of what Oliver said. We aim for compatibility with GNU in most
> (all?) of
2020 Feb 06
2
compatibility with gnu binutils
On Thu, Feb 6, 2020 at 9:15 AM James Henderson <jh7370.2008 at my.bristol.ac.uk>
wrote:
>
> On Thu, 6 Feb 2020 at 00:24, Jon Chesterfield via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> This doesn't sound right. GNU binutils have a large quantity of legacy
>> cruft, not least the redundancy between tools like readelf and objdump
>> which are
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
2012 Nov 06
0
[LLVMdev] Binutils and LLVM - gathering information
On Tue, Nov 6, 2012 at 2:19 PM, Marshall Clow <mclow.lists at gmail.com> wrote:
> Binutils and LLVM
>
> As part of "owning our own toolchain", various people have expressed an interest and have been working on creating various tools that duplicate the functionality of tools available on other systems.
>
> As a start, I'd like to summarize the current status, and
2018 Mar 08
2
[cfe-dev] [GSOC 2018] Information gathering
Hi Eric,
As you are pointed to be the confirmed mentor for the "Command line
replacements for GNU Binutils" GSOC 2018 subject, I permit myself to add
you to this thread !
If you have a few minutes to answer my questions, that'd really great 🙂
On 03/01/2018 08:43 PM, Paul Semel wrote:
> Hey,
>
> On 02/20/2018 11:51 PM, Paul Semel wrote:
>> Hello,
>>
2019 Apr 16
4
Accept --long-option but not -long-option for llvm binary utilities
Many llvm utilities use cl::ParseCommandLineOptions()
(include/Support/CommandLine.h) to parse command line options. The cl
library accepts both -long-option and --long-option forms, with the single
dash form (-long-option) being more popular.
We also have many binary utilities (llvm-objcopy llvm-objdump llvm-readobj
llvm-size ...) whose names reflect what they imitate. For compatibility
with GNU
2018 Mar 16
2
[cfe-dev] [GSOC 2018] Information gathering
Hi Eric,
On 03/15/2018 04:33 PM, Eric Christopher wrote:
> Hi Paul,
>
>
> >> I'm also interested in the command line replacements for GNU
> Binutils :
> >>
> >> - What tools would you like to replace in priority ?
> >> - Does this subject imply to add options/features to some of the
> >> tools, or is it only
2019 Apr 20
2
Accept --long-option but not -long-option for llvm binary utilities
> Are you proposing to make this the new style across all LLVM utilities?
No. Only drop --long-option for GNU binutils replacements (people sometimes
call them LLVM binary utilities): llvm-objcopy (D60439), llvm-ar,
llvm-size, llvm-nm, etc. llvm-objdump (not sure what to do with mach-o
specific dump options), llvm-readelf (not sure what to do with llvm-readobj)
On Sat, Apr 20, 2019 at 2:13 AM
2018 Mar 20
2
[cfe-dev] [GSOC 2018] Information gathering
Hi,
On 03/20/2018 06:05 AM, Eric Christopher wrote:
>
>
> On Fri, Mar 16, 2018 at 1:57 AM Paul Semel <semelpaul at gmail.com
> <mailto:semelpaul at gmail.com>> wrote:
>
> Hi Eric,
>
>
> On 03/15/2018 04:33 PM, Eric Christopher wrote:
>> Hi Paul,
>>
>>
>> >> I'm also interested in the command line
2019 Apr 16
2
Accept --long-option but not -long-option for llvm binary utilities
For binutil compatibility, and in general for any new tools, this sounds
reasonable to me. But I'd worry that things like llvm-readobj have existed
for a long time and people are used to flags like "-sections", and it may
be complicated to change that now. (I guess this RFC is a check to see if
this is true for anyone on the mailing list).
What happens if you make this change and
2019 Jun 27
2
RFC: llvm-readelf Mach-O & COFF options
Hi all,
llvm-readelf is an alias for llvm-readobj which aims for GNU compatibility
and is likely the tool that most people migrating to the LLVM binutils will
adopt instead of llvm-readobj. Because it is just an alias, it has
inherited the functionality provided by llvm-readobj, including for non-ELF
targets, with Mach-O and COFF-specific switches available in its interface.
People migrating from
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
2019 Apr 17
2
Accept --long-option but not -long-option for llvm binary utilities
It's actually a bit weirder than you might think. The CommandLine parser
will happily eat as many dashes as you care to write, e.g., `----sections`
is the same as `-sections`.
On Tue, Apr 16, 2019 at 2:11 AM James Henderson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> As I think I said elsewhere, I find it weird that LLVM tools accept long
> arguments with a single dash,
2018 Mar 20
0
[cfe-dev] [GSOC 2018] Information gathering
On Fri, Mar 16, 2018 at 1:57 AM Paul Semel <semelpaul at gmail.com> wrote:
> Hi Eric,
>
> On 03/15/2018 04:33 PM, Eric Christopher wrote:
>
> Hi Paul,
>
>
>> >> I'm also interested in the command line replacements for GNU Binutils :
>> >>
>> >> - What tools would you like to replace in priority ?
>> >> - Does this
2018 Mar 15
0
[cfe-dev] [GSOC 2018] Information gathering
Hi Paul,
> >> I'm also interested in the command line replacements for GNU Binutils :
> >>
> >> - What tools would you like to replace in priority ?
> >> - Does this subject imply to add options/features to some of the
> >> tools, or is it only about handling command line ?
> >
>
I just replied with this in another thread:
2018 Mar 25
0
[cfe-dev] [GSOC 2018] Information gathering
Hi,
On 03/20/2018 03:06 PM, Paul Semel wrote:
> Hi,
>
> On 03/20/2018 06:05 AM, Eric Christopher wrote:
>>
>>
>> On Fri, Mar 16, 2018 at 1:57 AM Paul Semel <semelpaul at gmail.com
>> <mailto:semelpaul at gmail.com>> wrote:
>>
>> Â Â Â Hi Eric,
>>
>>
>> Â Â Â On 03/15/2018 04:33 PM, Eric Christopher wrote:
>>> Â Â Â Hi