search for: objdump

Hey folks, This is great to see more interest on the supporting tools like objdump and such. I very much agree that bringing llvm-objdump up to feature parity (to start with) compared to both otool(1) and objdump(1) is a great goal. The default output formatting is easy enough to get right by having it be controlled by the container format (otool style for macho, objdump style fo...

Hello LLVM, Previously, some folks wanted llvm-objdump to behave more like GNU objdump. This could encompass both command line options and output format. Such a change helps developers already familiar with GNU tools and allows re-use of Perl scripts or other automation expecting to see GNU style dumps. Is moving llvm-objdump toward GNU objdump the...

Hi, In a 32-bit ARM build, I am seeing the following warning (edited for simplicity, I can provide full logs if necessary): > llvm-objdump -l -d -x file.elf > llvm-objdump: warning: 'file.elf': failed to parse debug information for file.elf All object files and static libraries seem to have debug info (i.e., llvm-objdump does not complain when run on each file individually and the disassembly output shows file/line inform...

...s obvious that there’s really not much of anything in common other than the general nature of the tools, it’s easy to split them apart. -Jim > On Dec 1, 2014, at 5:20 PM, Steve King <steve at metrokings.com> wrote: > > Hi guys, thanks for responding. Will mimicking both otool and objdump > in one binary become unwieldy? Maybe a disassembler library would be > a better way to factor out common code? For example, will Kevin's > symbolizing work be relevant for ELF files? > Regards, > -steve > > > On Mon, Dec 1, 2014 at 4:50 PM, Jim Grosbach <grosbac...

...need some help from Chris to track this down. I’ll bug him in a bit to see if he can help us on this. While the build here with -DLLVM_LINK_LLVM_DYLIB:BOOL=ON passed on the cmake options produces HAVE_LIBXAR:INTERNAL=1 in CMakeCache.txt, I don't see anything in the cmakefiles for tools/llvm-objdump to provide the necessary linkage on the system libxar shared library. Appending the missing linkage for -lxar onto build/stage1tools/llvm-objdump/CMakeFiles/llvm-objdump.dir/link.txt... /sw/src/fink.build/llvm39-3.9.0-1/opt-bin/ccclang++ -fno-common -fPIC -fvisibility-inlines-hidden -Wall -W -Wn...

...gt; -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib >> is created with -Wl,-dead_strip such that any symbols from libxar not >> explicitly used with in the object files of libLLVM.dylib are stripped >> out. This means that those additional symbols used by llvm-objdump >> aren't accessible from libLLVM.dylib's linkage on libxar and an >> additional explicit linkage on libxar is required in the >> tools/llvm-objdump/CMakeLists.txt when HAVE_LIBXAR and >> LLVM_LINK_LLVM_DYLIB are set. >> Jack > > Also note that th...

...eing linked against -lxar when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib is created with -Wl,-dead_strip such that any symbols from libxar not explicitly used with in the object files of libLLVM.dylib are stripped out. This means that those additional symbols used by llvm-objdump aren't accessible from libLLVM.dylib's linkage on libxar and an additional explicit linkage on libxar is required in the tools/llvm-objdump/CMakeLists.txt when HAVE_LIBXAR and LLVM_LINK_LLVM_DYLIB are set. Jack > >> On May 24, 2016, at 11:00 AM, Jack Howarth <howarth.mai...

OK. Let's try a specific example: At least for ELF files, GNU objdump prints operand values in hex. AFAIK, hex is not just the default, but the only choice. On the other hand, llvm-objdump prints operand values in decimal and ignores the --print-imm-hex option for ELF. How about a patch to print operands in hex for ELF? Good place to start? On Mon, Dec 1, 2014 a...

...Chris to track this down. I’ll bug him in a bit to see if he can help us on this. > > While the build here with -DLLVM_LINK_LLVM_DYLIB:BOOL=ON passed on > the cmake options produces HAVE_LIBXAR:INTERNAL=1 in CMakeCache.txt, I > don't see anything in the cmakefiles for tools/llvm-objdump to provide > the necessary linkage on the system libxar shared library. Appending > the missing linkage for -lxar onto > build/stage1tools/llvm-objdump/CMakeFiles/llvm-objdump.dir/link.txt... > > /sw/src/fink.build/llvm39-3.9.0-1/opt-bin/ccclang++ -fno-common > -fPIC -fvisibili...

...-lxar when > -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib > is created with -Wl,-dead_strip such that any symbols from libxar not > explicitly used with in the object files of libLLVM.dylib are stripped > out. This means that those additional symbols used by llvm-objdump > aren't accessible from libLLVM.dylib's linkage on libxar and an > additional explicit linkage on libxar is required in the > tools/llvm-objdump/CMakeLists.txt when HAVE_LIBXAR and > LLVM_LINK_LLVM_DYLIB are set. > Jack Also note that this issue doesn't arise fo...

While trying to fix a bug where llvm-objdump isn't printing relocations retained with ld -emit-relocs in shared object or executables, it seems like there isn't a way to split printing dynamic relocations from non-dynamic relocations as with GNU objdump -r and -R. I was thinking of adding a function RelocationRef::isDynamic() and fil...

...ses of those symbols appear bracketed in >>> HAVE_LIBXAR, so I don't know what went wrong for you. >> >> The trigger for this build failure is the usage of >> -DLLVM_BUILD_EXTERNAL_COMPILER_RT:BOOL=ON. If I drop that cmake >> option, the linkage failure for llvm-objdump disappears. > > Wrong cmake option. I meant to say that -DLLVM_LINK_LLVM_DYLIB:BOOL=ON > is the trigger of the build failure. Sorry for the noise there. Filed as https://llvm.org/bugs/show_bug.cgi?id=27855 > >> >>> >>> On Tue, May 24, 2016 at 8:07 AM, Jack Howa...

Is anyone else seeing a bootstrap failure on x86_64-apple-darwin15 in current trunk? [ 95%] Linking CXX executable ../../bin/llvm-objdump Undefined symbols for architecture x86_64: "_xar_serialize", referenced from: DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, unsigned int, bool, bool, bool, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) in...

...as a cmake > feature test, and all the uses of those symbols appear bracketed in > HAVE_LIBXAR, so I don't know what went wrong for you. The trigger for this build failure is the usage of -DLLVM_BUILD_EXTERNAL_COMPILER_RT:BOOL=ON. If I drop that cmake option, the linkage failure for llvm-objdump disappears. > > On Tue, May 24, 2016 at 8:07 AM, Jack Howarth via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Is anyone else seeing a bootstrap failure on x86_64-apple-darwin15 in >> current trunk? >> >> [ 95%] Linking CXX executable ../../bin/llvm-objd...

...appear bracketed in >>>> HAVE_LIBXAR, so I don't know what went wrong for you. >>> >>> The trigger for this build failure is the usage of >>> -DLLVM_BUILD_EXTERNAL_COMPILER_RT:BOOL=ON. If I drop that cmake >>> option, the linkage failure for llvm-objdump disappears. >> >> Wrong cmake option. I meant to say that -DLLVM_LINK_LLVM_DYLIB:BOOL=ON >> is the trigger of the build failure. Sorry for the noise there. > > Filed as https://llvm.org/bugs/show_bug.cgi?id=27855 > >> >>> >>>> >>>...

...ock project uses remap-path-prefix [1] to create a reproducible build. This means that the paths inside of built artifacts are not full source paths. When we later attempt to produce a listings file, the source mapping fails. The result is many copies of this recently merged warning [2]: llvm-objdump: warning: '/Volumes/code/helena-project/tock/target/thumbv7em-none-eabi/release/hail.elf': failed to find source chips/sam4l/src/eic.rs It looks like GNU objdump provides a --prefix option to address this exact problem [3]: * --prefix=**prefix* Specify *prefix* to add to the absolu...

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

...R, so I don't know what went wrong for you. On Tue, May 24, 2016 at 8:07 AM, Jack Howarth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Is anyone else seeing a bootstrap failure on x86_64-apple-darwin15 in > current trunk? > > [ 95%] Linking CXX executable ../../bin/llvm-objdump > Undefined symbols for architecture x86_64: > "_xar_serialize", referenced from: > DumpBitcodeSection(llvm::object::MachOObjectFile*, char const*, > unsigned int, bool, bool, bool, std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::alloc...

...test, and all the uses of those symbols appear bracketed in >> HAVE_LIBXAR, so I don't know what went wrong for you. > > The trigger for this build failure is the usage of > -DLLVM_BUILD_EXTERNAL_COMPILER_RT:BOOL=ON. If I drop that cmake > option, the linkage failure for llvm-objdump disappears. Wrong cmake option. I meant to say that -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is the trigger of the build failure. Sorry for the noise there. > >> >> On Tue, May 24, 2016 at 8:07 AM, Jack Howarth via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> Is a...

...ffset() - ContainingSection.getFileOffset() And to get the address relative to the section, I do: Symbol.getFileOffset() - 2*ContainingSection.getFileOffset() I suspect this isn't the desired functionality (what use is the original value?)? You can also see the impact of this on the tool llvm-objdump (as well as llvm-nm), as shown below: Normal objdump: http://pastebin.com/Fsv3Vvye vs llvm-objdump: http://pastebin.com/MRryQe4D I believe r148653 caused this, but haven't verified directly.  This didn't happen as of r148100. Am I missing something (my code borrows a good deal from llvm-...