similar to: [LLVMdev] .align 0

Hi Sid, It seems Apple's assembler used to treat .align 0 differently: https://developer.apple.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

Apple’s assembler does use power-of-two for .align. I believe binutils does as well. I suspect the header file comment is in error and what’s actually happening is that the section in question has a minimum alignment on the system(s) in question, and so it just looks like it’s redundant. That is, I doubt we need to do anything here. -Jim On Oct 28, 2013, at 11:54 AM, Renato Golin

".align 0" triggers the following error: a.s:2:8: error: alignment must be a power of 2 .align 0 ^ In this case would it be reasonable to query the target for a default or minimum value? Only targets not implementing this would error out. Thanks, On 10/28/2013 03:00 PM, Jim Grosbach wrote: > Apple’s assembler does use power-of-two for .align. I believe binutils > does

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 >

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

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

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 equivalent to the following? What do you

On 06/25/2013 04:46 PM, Jim Grosbach wrote: > 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? > A packet contains 1-4 insns and until the contents of the entire packet are known the meaning of any individual insn is not known with 100%

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

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,

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

Hi All, I am looking for a ABI Documentation of the X86 architecture to understand how LLVM converts its IR to X86 target instructions. Please guide me from where i can get the resources. Thanks, Shashidhar -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130226/05855007/attachment.html>

Shashidhar, Here's it for 32 and 64 bits. https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html#//apple_ref/doc/uid/TP40002492-SW4 https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/140-x86-64_Function_Calling_Conventions/x86_64.html -Dmitry. On Tue, Feb 26,

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::createELFObjectFile the > pointer to

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

I'd like to convert the following call A at GDPLT //R_HEX_GD_PLT_B22_PCREL to call __tls_get_addr //R_HEX_B22_PCREL "A" is a TLS variable and preceding code has prepared for the call. When the R_HEX_GD_PLT_B22_PCREL is found it will initially point to the TLS variable so at that point I'd like to define a __tls_get_addr symbol and update the relocation's type and symbol

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,