search for: otoole

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 for ELF). Kevin’s

At least for now, I don’t expect it to become all that unwieldy. Any behavioral differences should be easily separable into different classes and source files. If as things progress it becomes 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

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 at 5:49 PM, Kevin Enderby

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 general preference? And what about otools

Hello Tim, Rafael, Renato and llvmdev, I’m working to get llvm-objdump handle both arm and thumb disassembly from the same object file similarly to how darwin’s otool(1) works. And I’m looking for implementing direction. I spoke to Jim Grosbach about some ideas and he suggested I send out and email about some of the possibilities. Since none of the ones I could think of are pretty he thought

Hi, if I want to use 'llvm-gcc' I get: dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib Referenced from: /Users/me/llvm/gcc/bin/llvm-gcc Reason: Incompatible library version: llvm-gcc requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0 Trace/BPT trap So I installed MacPorts and 'libiconv', but I get the same error message. But it _should_

Hi Kev, I'm glad to hear llvm-objdump is getting attention. I'm unclear on how much output specialization one could (or should) do for ELF vs. Mach-O. If you're game, let's compare an example: $ cat labeltest.s .text foo: nop bar: bum: nop jmp bar jmp bum jmp baz nop baz: nop Assembling for x86 and llvm-objdump'ing, i get $ llvm-mc

Liam O'Toole <liam.p.otoole at ...> writes: > I doubt it. As you say, the NSS version is the blocker. Maybe that > number will get bumped in a future 6.x release. > Maybe. Centos-7 would probably do the job but this machine is 32-bit so it's a non-starter AFAIK.

Hi all, Will ldd display the paths to different libraries depending on their locations? I'm trying to build libxml2 version 2.9.6 in /usr/local with a newer version of zlib (1.2.8) than what are in the system folders for CentOS 6.8. I get the following output from ldd: $ ldd ./libxml2.so ./libxml2.so: /lib64/libz.so.1: version `ZLIB_1.2.3.3' not found (required by ./libxml2.so)

Hi, I'm trying to load the vorbis libs dynamicly on Mac OS X. I've got success for libogg, libvorbis and libvorbisfile. But libvorbisenc drives me crazy. The function "vorbis_encode_init" seems not to be in there if I am using "NSLookupSymbolInImage". But the tools "otool" and "nm" tell me that the function is declared. Does anyone know, what I

On 2015-04-08, Leon Fauster <leonfauster at googlemail.com> wrote: > Am 08.04.2015 um 16:22 schrieb Liam O'Toole > <liam.p.otoole at gmail.com>: >> On 2015-04-08, David Both >> <dboth at millennium-technology.com> >> wrote: >>> The easy way to restart gdm is when you are on the login screen >>> itself or the desktop simply press Ctrl-Alt-Backspace. This works >>> for Upsta...

This might be a stupid question, but here goes... Would adding, say, 4 4 or 8gb usb keys as a zil make enough of a difference for writes on an iscsi shared vol? I am finding reads are not too bad (40is mb/s over gige on 2 500gb drives stripped) but writes top out at about 10 and drop a lot lower... If I where to add a couple usb keys for zil, would it make a difference? Thanks. Sent from a

On Mon, Mar 6, 2017 at 5:54 PM, Moritz Angermann <moritz.angermann at gmail.com > wrote: > Hi Peter, > > I’ve just experimented with this a bit: > > Say we would end up with the following assembly: > > .section __TEXT,__text > .globl _main > > .long 1 > _main: > inc %eax > ret > > .globl _main.dsp > .alt_entry _main.dsp

Hi Kent, My guess is you are getting some new bit of info in your object files and your ranlib(1) is older and doesn't know about it. If you can send me the .o file or the output of otool(1) with the -hlv options on your object file I can take a look. Kev P.S. you can find out the version of ranlib(1) you have by running strings(1) on it and grep(1)'ing for the string

Hi all, I'm trying to figure out a problem with relocation types 1 and 8 (as observed using otool -r on ARM/Thumb object files). Earlier, when I used LLVM 2.8 with llc to generate thumb (-march=thumb -mattr=+thumb2) assembly listings, then assemble those using the gcc of iPhone 4.2 SDK, there wasn't any problem. However starting with LLVM 2.9, the same toolchain emits slightly different

Firstly, do you need "main.dsp" defined as an external symbol, or can all external references go via "main"? If the answer is the latter, that will make the solution simpler. If only the latter, you will need to make a change to LLVM here: http://llvm-cs.pcc.me.uk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp#650 Basically you would need to add a hook to the TargetLoweringObjectFile

Ran into this today -- rebuilt the SVN Trunk for this morning of LLVM+CLANG. Now every time my builds try and make a library from .o files, ranlib complains about 'malformed object' files. This is with OS X 10.7.4, and the binary tools from XCode 4.4.1 ld -v @(#)PROGRAM:ld PROJECT:ld64-127.2 llvm version 3.0svn, from Apple Clang 3.0 (build 211.12) ranlib doesn't tell you what

> On Feb 27, 2016, at 4:36 AM, Jun Koi via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The problem is that llvm-mc always compiles "jmp" this as short jump, no matter where the target is. Hence my question. I dont know if there is any way to change this behavior. Looks like a bug to me so far. It isn't. It's just created some assembly which, when assembled, may

Here you go: http://www.cornwarning.com/xfer/jccolor.o (from the jpeg library...) jccolor.o: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC_64 X86_64 ALL 0x00 OBJECT 4 432 SUBSECTIONS_VIA_SYMBOLS Load command 0 cmd LC_SEGMENT_64 cmdsize 312 segname vmaddr 0x0000000000000000 vmsize 0x0000000000000900

On Apr 1, 2010, at 3:58 PM, Chris Lattner wrote: > It's hard to say: __ZTVN4llvm14raw_os_ostreamE is the vtable for > raw_os_ostream. This should be provided by lib/Support/ > raw_os_ostream.cpp. Perhaps you're not linking in that .o file for > some reason. raw_os_ostream is definitely linked into Debug/lib/libLLVMSupport.a in my LLVM build. (Confirmed with otool.)