similar to: [LLVMdev] llvm-objdump fails on bunch of archs

On Thu, Nov 28, 2013 at 1:03 AM, Kay Tiong Khoo <kkhoo at perfwizard.com>wrote: > Hi Jun, > > I'm not sure how to fix this yet, but this looks incorrectly defined in > lib/Target/X86/X86InstrInfo.td: > > def MOV32o32a : Ii32 <0xA1, RawFrm, (outs), (ins offset32:$src), > "mov{l}\t{$src, %eax|eax, $src}", [], IIC_MOV_MEM>, >

Hi Jun, I'm not sure how to fix this yet, but this looks incorrectly defined in lib/Target/X86/X86InstrInfo.td: def MOV32o32a : Ii32 <0xA1, RawFrm, (outs), (ins offset32:$src), "mov{l}\t{$src, %eax|eax, $src}", [], IIC_MOV_MEM>, Requires<[In32BitMode]>; This instruction can be REX-prefixed for a 64-bit move, and that also

On Wed, Oct 12, 2011 at 3:17 AM, Songmao <smtian at ingenic.cn> wrote: > Michael, >    I have rework the patch according to your suggestion.  And I have read > binutil/objdump source code and found that it has a logic that if there's no > symtab, it will use dynsym, which is missing in llvm-objdump. > > Songmao > @@ -747,12 +747,28 @@ error_code

Hi, With objdump, i have this (Intel syntax) 64 a1 00 00 00 00 mov eax,fs:0x0 However, if I pass above string to llvm-mc, I would have: $ echo "0x64 0xa1 0x00 0x00 0x00 0x00"|./Release+Asserts/bin/llvm-mc -disassemble -arch=x86 --output-asm-variant=1 .text mov eax, dword ptr [0] You can see a big difference. This is on the latest code. Any idea how to

On Thu, Jun 26, 2014 at 5:47 AM, Adam Nemet <anemet at apple.com> wrote: > Hi Jun, > > On Jun 25, 2014, at 8:14 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > Hi, > > > > I am trying to assemble below instruction with latest LLVM code, but > fail. Am I doing something wrong, or is this a bug? > > > > > > $ echo "vaddps zmm7

On Thu, Jun 26, 2014 at 10:23 AM, Adam Nemet <anemet at apple.com> wrote: > > > On Jun 25, 2014, at 7:05 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > > > On Thu, Jun 26, 2014 at 5:47 AM, Adam Nemet <anemet at apple.com> wrote: > >> Hi Jun, >> >> On Jun 25, 2014, at 8:14 AM, Jun Koi <junkoi2004 at gmail.com> wrote: >>

I agree with the others that this seems great! I think this information can be super helpful for users both in learning and skimming assembly codes. As a maintainer of a LLVM frontend (JuliaLang), I'm additionally interested in whether some bits of this make sense to end up in libLLVM itself. Probably especially the collection code pieces. For context, I've previously written some code to

Michael, I have rework the patch according to your suggestion. And I have read binutil/objdump source code and found that it has a logic that if there's no symtab, it will use dynsym, which is missing in llvm-objdump. Songmao -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-the-address-calculation-for-llvm-objdump.patch Type: text/x-patch

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 filtering them this way when printing. Since RelocationRef

Hello i see that the address of specific symbol are not the same between llvm-objdump and objdump. The code: --- #include <stdio.h> int machin = 42; int main () { printf("Hello : %d\n", machin); return 0; } ---- compile command: clang hello1.c -o hello1 And the address of the symbol of the global variable "machin": [ Fri Mar 08 - 22:58:36 ][ wwolff at hostname

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

On Thu, Oct 17, 2013 at 10:55 AM, Stephen Checkoway <s at pahtak.org> wrote: > 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 >

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

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

Hi, We are trying to use LLVM API to programmatically obtain a list of relocations in an ELF file. The way we are doing this is exactly as llvm-objdump does it: we are iterating through sections and in each section we are iterating over relocations (see PrintRelocations() function at https://llvm.org/svn/llvm-project/llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp). However, it does not give us

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

Kevin Enderby added those symbol uses in r270491. It has 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. 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? > > [

Hi, I would like to examine the implications you mention in more detail. (1) Symbol address According to the ELF standard, in a symbol table entry st_value means: "In relocatable files, st_value holds a section offset for a defined symbol. That is, st_value is an offset from the beginning of the section that st_shndx identifies." (*) Therefore, when queried about a symbol's

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 all the uses of those symbols appear bracketed in >> HAVE_LIBXAR, so I don't know what went wrong for you.

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> 2: c3 retq