similar to: 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

Sounds good, I'll work on removing these in favor of defaulting to stdin then? > I think it would be much friendlier to just print "file or pipe expected" and then print the help. Do you have thoughts on this? I'm not sure there is a clean way to do this, the cleanest would be through getFileOrSTDIN(), but I'm not sure all of its users want this behavior. I don't

> Does anyone actually use the default to a.out behavior? This is a good point. What bugs me is continuity across the tools, I agree with you that it isn't particularly useful to default to a.out. But we are kind of stuck with the weird way that GNU's binutils do things. I am not in favor of llvm-objdump defaulting to a.out, but llvm-readelf giving this warning message. My guess is that

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

Like James, Michael suggested, I would prefer the default behavior be consistent across tools (either always read from stdin or no default at all /give error messages) From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent: Wednesday, June 26, 2019 2:31 AM To: Alex Brachet-Mialot <alexbrachetmialot at gmail.com> Cc: Fāng-ruì Sòng <maskray at google.com>; LLVMDev

I have been working towards this on D63859. My current route was to add an optional callback to MemoryBuffer::getFileOrSTDIN which will be executed if stdin has not been redirected. James and I were talking over there and are maybe deciding that this might not be the best solution. The alternative in my mind is that the tools which want this behavior could do so by explicitly testing if

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

Hi all, I was giving some thought as to possible project ideas I could propose for this year’s Google Summer of Code, with regards to the LLVM Binutils. One idea that I had was something discussed at last year’s Euro LLVM developer meeting, namely machine-readable output from the LLVM Binutils. Before I actually start advertising this as an open project, I wanted to ask a few questions:

I agree with the others that this seems great! I think this information can be super helpful for users both in learning and skimming assembly codes. As a maintainer of a LLVM frontend (JuliaLang), I'm additionally interested in whether some bits of this make sense to end up in libLLVM itself. Probably especially the collection code pieces. For context, I've previously written some code to

Hi all ! During this GSoC, I've worked on improving the llvm binutils suite. I've wrote a final [1]report for those of you who would be interested. Regards, -- Paul Semel [1] http://paulsemel.org/posts/command-line-replacements-in-llvm-binutils/

Some binutils, nm comes to mind, when to input file is specified will default to a.out. Others do not do this and read from stdin by default. The rest of this email will be specifically referencing these which read from stdin, and not the tools which for various reasons do things differently. I propose that we change the behavior of these tools to use a.out when appropriate. By appropriate I mean

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

> 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

Hi all, A broad goal of many of the LLVM binary tools, such as llvm-objcopy and llvm-objdump is to provide an alternative to the GNU equivalent, and as such, these tools have been developed to be command-line compatible. One tool where this hasn’t been the case up to now is llvm-readobj (aka llvm-readelf). There was some discussion in https://reviews.llvm.org/D33872 about the purpose of

Pinging this thread to see if anyone else has opinions or objections -- if not I plan to go ahead with stepping towards compatibility with readelf vs llvm-readelf in https://reviews.llvm.org/D54124 on Monday. On Tue, Nov 6, 2018 at 9:52 AM Jordan Rupprecht <rupprecht at google.com> wrote: > Hi James, > > I also wanted to work on this discrepancy, but I just sent a patch instead

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

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,

On Saturday, April 18, 2020, David Blaikie <dblaikie at gmail.com> wrote: > > > On Sat, Apr 18, 2020 at 3:02 AM Nagaraju Mekala via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello All, >> >> I was trying to add Microblaze target to LLVM backend. I was able to >> generate object file with relocations. and debug symbols. >>

On Tue, Apr 16, 2013 at 8:31 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Tue, Apr 16, 2013 at 2:37 AM, Alexey Samsonov <samsonov at google.com>wrote: > >> Hi! >> >> TL;DR WDYT of adding zlib decompression capabilities to LLVMObject >> library? >> > >> ld.gold from GNU binutils has --compress-debug-sections=zlib option,

On Sat, Apr 18, 2020 at 11:11 PM David Blaikie <dblaikie at gmail.com> wrote: > > Yeah, not sure - you mention the linker produces errors, but the errors you showed looked like objdump errors? Were those errors from trying to dump the linked executable, and not errors that were produced by the linker itself? Yes, as mentioned earlier I was able to generate final executable but it