similar to: [LLVMdev] [patch] Enhance of asm macros

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

Hi llvm users & developers! Attached patches: 1) rewrite previous patch, now for darwin platform applied old mechanism 2) patch added processing .rept directive 3) patch added processing .irp directive 4) patch added processing .irpc directive -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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

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

Hello! Could someone tell me does force security mode work only for permissions or it can also not allow users to change file attributes (f.e. , to set file read-only) ? I tried this with samba 2.2.8a and looks like force security mode doesn't work with file atttributes :-( Is this bug or feature ? :-)

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

I would like to add something to atttributes.h, attributes.cpp in the interim until your full scheme is available. A new attribute called "target" would be added to AttrKind. And target can take a list of strings. target("foo", "goo") For example. I would add a component targetAttrs to AttrBuilder Will this meet with resistance if I try and put this back? Reed

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

Looks like new attribute work is moving along quickly Maybe I should just wait. ??? On 01/11/2013 03:09 PM, Reed Kotler wrote: > I would like to add something to atttributes.h, attributes.cpp in the > interim until your full scheme is available. > > A new attribute called "target" would be added to AttrKind. > > And target can take a list of strings. > >

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

Seems to be largely untested... anyone using this? (cc'ing Kevin as he's the most likely candidate). At the least for MCAnalysis this appears to be unused, any ideas on what else can be deleted? I'll remove just this file unless there are objections tomorrow (or earlier if I get an ack from Kevin about it). -eric

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

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

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