search for: enderbi

Oops sorry. lib/MC/MCAnalysis/MCObjectDisassembler.CPP Thanks. -eric On Jul 31, 2014 1:21 PM, "Kevin Enderby" <enderby at apple.com> wrote: > Eric, what file are your referring to? The path > lib/MC/MCObjectDisassembler does not end in a .cpp or .h and is not a > directory . > > Just a bit more info and I can get back to you if I’m using what your > asking

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

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

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

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

On Tue, May 24, 2016 at 1:35 PM, Kevin Enderby <enderby at apple.com> wrote: > Hi Jack, > > Just a guess here, this may be the bug Chris helped me out with in the use of the include file xar/xar.h which is not C++ safe. I needed to wrap my include via: > > #ifdef HAVE_LIBXAR > extern "C" { > #include <xar/xar.h> > } > #endif > > I think we

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

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

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

Jack, What version of CMake are you using? -Chris > On May 24, 2016, at 11:00 AM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > > On Tue, May 24, 2016 at 1:35 PM, Kevin Enderby <enderby at apple.com> wrote: >> Hi Jack, >> >> Just a guess here, this may be the bug Chris helped me out with in the use of the include file xar/xar.h which is not

On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: > Jack, > > What version of CMake are you using? > > -Chris Chris, I am using cmake 3.5.2. My read of this problem is as follows. While libLLVM.dylib is being 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

Hi A quicky - has anyone had success with an X100P in the UK ? I'm seeing some oddness - when I plug the wall socket into the card, I lose dialtone. If I unplug it, it comes back. Does this sound familiar to anyone ? Cheers Nigel Nigel Taylor Technology Director ITAzure Limited Dunn House Warren Park Way Enderby Leicestershire LE19 4SA 0116 286 3016

Hi Jack, Just a guess here, this may be the bug Chris helped me out with in the use of the include file xar/xar.h which is not C++ safe. I needed to wrap my include via: #ifdef HAVE_LIBXAR extern "C" { #include <xar/xar.h> } #endif I think we may 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. Kev > On May 24, 2016, at

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

On Tue, May 24, 2016 at 1:24 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 1:22 PM, Jack Howarth > <howarth.mailing.lists at gmail.com> wrote: >> On Tue, May 24, 2016 at 12:08 PM, Reid Kleckner <rnk at google.com> wrote: >>> Kevin Enderby added those symbol uses in r270491. It has a cmake >>> feature test, and

Hello Vladimir, While this is great for platforms that use the current gas style assembler macros your patch also changes the existing support for darwin that does not use these style of assembler macros. Could you please update your patch that leaves the assembler macros unchanged for darwin. Then we can review the updated patch. Thanks, Kev On Feb 5, 2012, at 1:43 PM, Vladimir Sorokin

Hello Kevin, I thinking about this, but there are some problems: 1) Differrent interpretation of $[:number:] in macro body: source: .macro test par1 movl $0, %eax .endm test %ebx translated to: original llvm => movl %ebx, %eax with patch => movl $0, %ebx 2) Different parsing of space in macro parameters: source: test2 a + b,c parsed as: original llvm => macro test2 with two

Hello llvm users! I make patch of asm parser for make it to be closer to gas: 1) treat space as comma of parameters 2) support "req" & "vararg" atttributes 3) macro calls with with explicit named arguments Path attached. Can anybody review it? -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, May 24, 2016 at 2:37 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >> Jack, >> >> What version of CMake are you using? >> >> -Chris > > Chris, > I am using cmake 3.5.2. My read of this problem is as follows. > While libLLVM.dylib is

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