similar to: DWARF info in readobj

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

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

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:

Hi, The llvm-objdump tool at the moment disassembles ARM ELF binary but with lot of extra user supplied data * The triple supplied on the command line for tools has to be be correct (ARM, thumb etc) * The ELF file cannot have mix of ARM and thumb * There is no direct way of using it such as llvm-objdump -d elf_file. This works for architectures such as Hexagon, X86

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

Seeing the below commit, I wondered whether that's a genuine fix or rather a workaround for a shortcoming in llvm::ScopedPrinter::printNumber. The latter has overloads for [u]int{8,16,32,64}_t, presumably so that it can take arguments of arbitrary integer types. However, at least on recent macOS uint64_t is 'unsigned long long' (and uint32_t is 'unsigned int') while

> 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

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

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,

My personal preference is that llvm-readelf only show the elf related options with -help and show all with -help-hidden. There is support for this in CommandLine.h, but I don't know how tricky it gets when we don't want them to be hidden for llvm-readobj. I haven't looked into this fully. For some reference, I have compiled how the other alias tools are handled. Many of these are

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

Hi, Now in case of relocatable object generation LLD merges and copies REL/RELA sections as is and does not touch any addends. But it is incorrect. If we have a relocation which targets a section, we have to adjust the relocation's addend to take in account that the section might be merged with other ones. Here is the reproduction script: % cat t1.s .data .long 0 .text bar: movl $1,

It sounds like what you’re asking is, rather that universally calling RelocationRef::getOffset inside llvm-objdump.cpp I should: * Check if Obj “isRelocatableObject” * If it is, call RelocationRef::getOffset() * If it isn’t o Call RelocationRef::getAddress() o Build an ordered map of all sections and their bounds, check if the relocation lands within a section o

Hi All, While working on some recent patches for x32 support, I ran into an unpleasant limitation the LLVM eco-system has with testing DWARF emission. We currently have several approaches, neither of which is great: 1. llvm-dwarfdump: the best approach when it works. But unfortunately lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections like debug_frame aren't supported. 2.

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

On Fri, Jan 18, 2013 at 1:00 PM, Eli Bendersky <eliben at google.com> wrote: > Hi All, > > While working on some recent patches for x32 support, I ran into an > unpleasant limitation the LLVM eco-system has with testing DWARF > emission. We currently have several approaches, neither of which is > great: > > 1. llvm-dwarfdump: the best approach when it works. But

+ other debug info people (Eric & Paul) On Fri, Jan 18, 2013 at 1:00 PM, Eli Bendersky <eliben at google.com> wrote: > Hi All, > > While working on some recent patches for x32 support, I ran into an > unpleasant limitation the LLVM eco-system has with testing DWARF > emission. We currently have several approaches, neither of which is > great: > > 1.

With the correct list this time. On Wed, Sep 9, 2015 at 6:59 PM, Davide Italiano <davide at freebsd.org> wrote: > Hi, > in the last month I spent some time implementing the missing MachO > specific features in llvm-readobj, and converting all the remaining > tests that used macho-dump to the new format. > llvm-readobj should have all the functionality that macho-dump had. If

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