search for: sidneym

I've fixed this specific error in r164813. Please let me know if there are more behind it. On Thu, Sep 27, 2012 at 2:16 PM, Sid Manning <sidneym at codeaurora.org> wrote: > > I just updated my llvm sources (revision 164794.) and I see the error, > "overriding non-deleted function" when building with gcc 4.7.0 and passing > -std=c++11. > > /usr2/sidneym/llvm/tools/**install/bin/c++ -D_GNU_SOURCE -D_DEBUG &gt...

I just updated my llvm sources (revision 164794.) and I see the error, "overriding non-deleted function" when building with gcc 4.7.0 and passing -std=c++11. /usr2/sidneym/llvm/tools/install/bin/c++ -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++11 -fPIC -fvisibility-inlines-hidden -I/local/scratch/llvm-tmp/build/lib/VMCore -I/local/scratch/llvm-tmp/llvm/lib/VMCore -I/local/scratch/llvm-tmp/build/include -...

On 09/20/2013 06:00 PM, Eli Friedman wrote: > On Fri, Sep 20, 2013 at 2:50 PM, Sid Manning <sidneym at codeaurora.org > <mailto:sidneym at codeaurora.org>> wrote: > > > This example generates the following error: > .Ltmp3: > .Ltmp5: > .Ltmp13: > .word (.Ltmp5-.Ltmp3)-.Ltmp13 > > ./llvm-mc ex.s -filetype=obj > LLVM ER...

...ertools/Reference/Assembler/040-Assembler_Directives/asm_directives.html > > If this is still the case, than we should have an option for what to do in this case, maybe defaulting based on the triple? > > cheers, > --renato > > > On 28 October 2013 17:53, Sid Manning <sidneym at codeaurora.org> wrote: > > I have several assembly files in a testsuite that use, ".align 0". I found a reference to, ".align 0" in ARM's elf.h that says .align 0 is redundant and gas treats this as align 2. > > Should the llvm-mc follow this convention?...

...bler_Directives/asm_directives.html >> >> If this is still the case, than we should have an option for what to >> do in this case, maybe defaulting based on the triple? >> >> cheers, >> --renato >> >> >> On 28 October 2013 17:53, Sid Manning <sidneym at codeaurora.org >> <mailto:sidneym at codeaurora.org>> wrote: >> >> >> I have several assembly files in a testsuite that use, ".align 0". >> I found a reference to, ".align 0" in ARM's elf.h that says .align >> 0 is...

...the MCInsts for the whole packet and either the raw hex encodings or append the needed info as an operand stored in the MCInst. The reason I tried using MCOperand is that it kept me from having to change objdump itself. Thanks, > -Jim > > On Jun 25, 2013, at 8:24 AM, Sid Manning <sidneym at codeaurora.org > <mailto:sidneym at codeaurora.org>> wrote: > >> >> I'm working on a disassembler for hexagon (vliw) architecture and I >> would like to add an additional operand type, "kAux" to the MCOperand >> class. >> >> The re...

This example generates the following error: .Ltmp3: .Ltmp5: .Ltmp13: .word (.Ltmp5-.Ltmp3)-.Ltmp13 ./llvm-mc ex.s -filetype=obj LLVM ERROR: expected relocatable expression when using: -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

On Fri, Sep 20, 2013 at 2:50 PM, Sid Manning <sidneym at codeaurora.org> wrote: > > This example generates the following error: > .Ltmp3: > .Ltmp5: > .Ltmp13: > .word (.Ltmp5-.Ltmp3)-.Ltmp13 > > ./llvm-mc ex.s -filetype=obj > LLVM ERROR: expected relocatable expression when using: > > Umm, isn't this...

On Sun, Sep 22, 2013 at 12:23 PM, Sid Manning <sidneym at codeaurora.org>wrote: > On 09/20/2013 06:00 PM, Eli Friedman wrote: > >> On Fri, Sep 20, 2013 at 2:50 PM, Sid Manning <sidneym at codeaurora.org >> <mailto:sidneym at codeaurora.org**>> wrote: >> >> >> This example generates the following e...

On 06/30/2012 07:16 PM, Michael Spencer wrote: > On Sat, Jun 30, 2012 at 7:58 AM, Sid Manning<sidneym at codeaurora.org> wrote: >> >> I've been debugging a segfault issue with the elfreader and I would like to >> point out something that I have noticed. >> >> ELF.h declares an inline function, getElfArchType (MemoryBuffer *Object). >> When this function...

Hi Sid, This feels like it’s exposing too much of the disassembler internals into the MCOperand representation. I’m not sure I follow why that’s necessary. Can you elaborate a bit? -Jim On Jun 25, 2013, at 8:24 AM, Sid Manning <sidneym at codeaurora.org> wrote: > > I'm working on a disassembler for hexagon (vliw) architecture and I would like to add an additional operand type, "kAux" to the MCOperand class. > > The reason for this is that each insn has parse bits which are not explicit operands and...

I'm working on a disassembler for hexagon (vliw) architecture and I would like to add an additional operand type, "kAux" to the MCOperand class. The reason for this is that each insn has parse bits which are not explicit operands and have differing meanings based on the insn's location within the packet and the number of insns inside the packet. In order for the disassembler

...le.com/library/mac/documentation/developertools/Reference/Assembler/040-Assembler_Directives/asm_directives.html If this is still the case, than we should have an option for what to do in this case, maybe defaulting based on the triple? cheers, --renato On 28 October 2013 17:53, Sid Manning <sidneym at codeaurora.org> wrote: > > I have several assembly files in a testsuite that use, ".align 0". I > found a reference to, ".align 0" in ARM's elf.h that says .align 0 is > redundant and gas treats this as align 2. > > Should the llvm-mc follow this co...

I have several assembly files in a testsuite that use, ".align 0". I found a reference to, ".align 0" in ARM's elf.h that says .align 0 is redundant and gas treats this as align 2. Should the llvm-mc follow this convention? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

On Sat, Jun 30, 2012 at 7:58 AM, Sid Manning <sidneym at codeaurora.org> wrote: > > I've been debugging a segfault issue with the elfreader and I would like to > point out something that I have noticed. > > ELF.h declares an inline function, getElfArchType (MemoryBuffer *Object). >  When this function is called from ObjectFile...

I've been debugging a segfault issue with the elfreader and I would like to point out something that I have noticed. ELF.h declares an inline function, getElfArchType (MemoryBuffer *Object). When this function is called from ObjectFile::createELFObjectFile the pointer to Object was getting corrupted. The only thing that distinguished this pointer was that it was declared as a

On 06/27/12 07:24, Journeyer J. Joh wrote: > Hello, > > With your kind concern and help, I now can make a binary for ARM target. > > ./clang -v --save-temps -ccc-host-triple arm-none-linux-gnueabi > --sysroot=/home/hum/Documents/Projects/arm_toolchain/arm-2010.09/arm-none-linux-gnueabi/libc > -gcc-toolchain /home/hum/Documents/Projects/arm_toolchain/arm-2010.09 > hello.c -o

Should Elf_Dyn_Impl in Object/ELF.h also have a 32bit version. getTag/getVal/getPtr all return 64bit types however Elf_Addr etc will not always be 32bit?

It looks like llvm-mc isn't treating section relative expressions correctly. In this example: .text mov (.rodata+0), %rsi .section .rodata .byte 0xff llvm-mc will create an undefined symbol for the expression, ".rodata+0" and a relocation will be generated against the undefined symbol not the section. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,

Hello, With your kind concern and help, I now can make a binary for ARM target. ./clang -v --save-temps -ccc-host-triple arm-none-linux-gnueabi --sysroot=/home/hum/Documents/Projects/arm_toolchain/arm-2010.09/arm-none-linux-gnueabi/libc -gcc-toolchain /home/hum/Documents/Projects/arm_toolchain/arm-2010.09 hello.c -o hello The build command is shown above. After that, I prepared an ARM laptop,