similar to: [LLVMdev] section relative expressions

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

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

> De : Joerg Sonnenberger [mailto:joerg at britannica.bec.de] > > Well, MCFixup is what a relocation is represented as internally. They get > resolved to a fixed value and replaced, if evaluateAsAbsolute is true. > Hi Joerg, Actually it fails to get resolved to a fixed value. When I compile to .o then objdump it I can see that a symbol holding the constant value was created in

Thanks Reid/Jonathon for your replies. Reid, An important case against module level flags is that it wont allow changing or resetting section names e.g. int a; #pragma clang section bss = "xyz" int b; In case above, users would like to see only 'b' placed in 'xyz' and not 'a' as well. Link pointed to by Jonathon seems to require same behavior.

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

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

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

Reported https://bugs.llvm.org/show_bug.cgi?id=38911 Thanks, Leslie Zhai 在 2018年09月11日 16:55, Dimitry Andric 写道: > Hi Leslie, > > The problem really lies in the OpenJDK code, as it is attempting to > write to a const object. If this seems to work with certain compiler(s) > and optimization settings, it is just luck. :-) > > Here is a reduced example, which shows the

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 2020-09-16 00:18, Fangrui Song wrote: > Usually it is because nobody has noticed the problem or nobody is > motivated enough to fix the problems, not that they intentionally leave > a problem open:) I took some time to look at the problem and conclude > that clang should do nothing on this. Actually, with the clang behavior, > you can discard "Unused" if you use LLD.

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

Rafael Avila de Espindola wrote: >> $ gcc -o rodatareloc.s.o -c rodatareloc.s >> $ lld -o rodatareloc.so -shared rodatareloc.s.o >> >> ld: error: rodatareloc.s.o:(.rodata+0x0): can't create dynamic >> relocation >> R_X86_64_64 against local symbol in readonly segment defined in >> rodatareloc.s.o >> >> >> Changing the section from

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

Hi there, When I compile my code with -fdata-sections and -ffunction-sections, I still see some unused string in my shared library (Android). Actually, the strings appear together inside a .rodata.str1.1 section instead of getting their own section. It seems that the C-string literal are considered differently than other constant and the -fdata-sections is not respected in

Hi, the attached example works with bfd-ld and with gold, but not with lld: $ cat rodatareloc.s ... .align 16 leaq .JTab(%rip), %r10 jmp *(%r10, %rdx, 8) ... .section .rodata .JTab: .quad .L00, .L01, .L02, .L03, .L04, .L05, .L06, .L07 .quad .L08, .L09, .L10, .L11, .L12, .L13, .L14, .L15, .L16 $ gcc -o rodatareloc.s.o -c rodatareloc.s $ lld -o rodatareloc.so -shared

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