search for: otool

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 right that where this gets a bit interesting is command line option handling. The prevailing wisdom...

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

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

...his 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 style output? Regards, -steve

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 maybe you would have some thoughts or suggestions. First a little b...

...renced 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_ work, because otool -L /opt/local/lib/libiconv.2.dylib gives me: /opt/local/lib/libiconv.2.dylib: /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) Any hint what went wrong? Thanks a lot, Nico

...op 00000001 <bar>: 1: 90 nop 2: eb fd jmp 1 <bar> 4: eb fb jmp 1 <bar> 6: eb 01 jmp 9 <baz> 8: 90 nop 00000009 <baz>: 9: 90 nop What does otool produce? On Tue, Aug 26, 2014 at 11:16 AM, Kevin Enderby <enderby at apple.com> wrote: > For branch targets my preference is to print the target’s address (not the displacement of the branch), and preferably in hex. I like this too. > I don’t think having multiple addresses for a ta...

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.

....so.1 (0x00007fce9e60e000) <-- I expected /usr/local/lib here libm.so.6 => /lib64/libm.so.6 (0x00007fce9e389000) libc.so.6 => /lib64/libc.so.6 (0x00007fce9dff5000) /lib64/ld-linux-x86-64.so.2 (0x0000003d52a00000) Yet the make itself for libxml2 seemed to exit without error. >From otool on Mac OSX (same installation of libxml2/zlib) I see: %otool -L libxml2.2.dylib libxml2.2.dylib: /usr/local/lib/libxml2.2.dylib (compatibility version 12.0.0, current version 12.6.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12) /usr/loc...

..., 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 have to do to get this working ? arne --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-d...

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

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

...fact, pointing to the start of > the prefix data) > > this will yield: > > $ clang test.s -dead_strip > ld: warning: N_ALT_ENTRY bit set on first atom in section __TEXT/__text > And the prefix data will be stripped again. > > E.g. what you end up getting is: > > $ otool -vVtdj a.out > a.out: > _main: > 0000000100000fb5 ff c0 incl %eax > 0000000100000fb7 c3 retq > > instead of what we’d like to get: > > otool -vVtdj a.out > a.out: > _main.dsp: > 0000000100000fb1 01 00 addl %eax, (%rax) > 000000...

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 "cctools". On Sep 26, 2012, at 2:19 PM, Kent Williams wrote: > Ran into this today -- rebuilt t...

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

...hat seems to do the trick! > > $ cat test.s > .section __TEXT,__text > .globl _main > > .long 1 > _main: > inc %eax > ret > > .alt_entry _main > _main.dsp = _main-4 > > .subsections_via_symbols > > > $ clang test.s -dead_strip > $ otool -vVtdj a.out > a.out: > _main.dsp: > 0000000100000fb1 01 00 addl %eax, (%rax) > 0000000100000fb3 00 00 addb %al, (%rax) > _main: > 0000000100000fb5 ff c0 incl %eax > 0000000100000fb7 c3 retq > > > > However, now I need...

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

...is then run through the compiler. $ echo "jmp _label"|llvm-mc-mp-3.7 -assemble -triple=i386 -show-encoding |tee b.s .text jmp _label # encoding: [0xeb,A] # fixup A - offset: 1, value: _label-1, kind: FK_PCRel_1 $ clang -c b.s $ otool -tvj b.o b.o: (__TEXT,__text) section 0000000000000000 e900000000 jmp 0x5 As you can see, both produced near jumps. (I assume the difference between the offsets has to do with a difference in relocations between ELF and Mach-o.) -- Stephen Checkoway

...nlocrel 0 On Wed, Sep 26, 2012 at 4:31 PM, Kevin Enderby <enderby at apple.com> wrote: > 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 "cctools". > > On Sep 26, 2012, at 2:19 PM, Kent Williams wrote: > >&g...

...aw_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.) I'm using the 2.7 release branch from a couple weeks ago. Just for kicks, I added some code to my pass that creates a circular_raw_ostream object, and it runs without errors. I wonder what's different about raw_os_ostream... Any other possibilities? Trevor