similar to: [LLD] Can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment

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

Hi Martin, The key is available on the keys.gnupg.net key server. I'm also attaching it to this email for convenience. Would posting it on the release page really help? The user would still need to trust the page to trust the key. Thanks, Hans On Mon, Mar 2, 2015 at 5:58 AM, Richtarsky, Martin <martin.richtarsky at sap.com> wrote: > Hi Hans, > > I want to verify the

Hi Rui, I still fail to enable the lld in my Uefi firmware build to replace ld, and I found it is related to the wrong symbol values in the .data section, which are pointed by R_X86_64_64 relocation entries. I need your advices. My firmware uses a linker script https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/GccBase.lds to do the linking. We use position independent code with

Hi Rui, > but why don't you use lld-link (lld for Windows target) instead of ld.lld (lld for Unix target) to create UEFI applications? I need support both PE/COFF and ELF format tools. I’m also working on the lld-link enabling (clang-cl + lld-link) in both Linux and windows. The ld.lld enabling (clang + ld.lld) is for ELF format native users. E.g.

Hi Rui, A quick question: Does lld-link only work with clang-cl with windows-msvc option? Can lld-link work with clang with linux-gnu option? Thanks Steven Shi Intel\SSG\FID\Firmware Infrastructure From: Shi, Steven Sent: Tuesday, January 29, 2019 1:32 PM To: 'Rui Ueyama' <ruiu at google.com> Cc: llvm-dev at lists.llvm.org Subject: RE: lld write wrong symbol value in .data

I would think that the R_X86_64_PC32 relocation type should never be generated with large code model since large code model, by definition, makes no assumptions about the size or address of sections. The use of win32-elf might throw a wrinkle into this, since that is a code path that probably isn't exercised much outside of MCJIT use. That said, when this assertion fails it is usually

Hello, We've recently started using ifuncs in the x86(_64) FreeBSD kernel. Currently lld will emit a PLT entry for each ifunc, so ifunc calls are more expensive that those of regular functions. In our kernel, this overhead isn't really necessary: if lld instead emits PC-relative relocations for each ifunc call site, where each relocation references a symbol of type GNU_IFUNC, then during

Hi, for programs linked with lld it's substantially slower to get callstacks in gdb, in comparison to gold-linked programs. Two measurements: lld gold 15 sec 3 sec 6 sec 2 sec This is a debug build, rather large binaries (lots of templates). I have seen even worse performance for debug+UBSan builds. I think code size (and therefore DWARF size) has an impact. Is there some information

Martin Richtarsky <s at martinien.de> writes: > Output looks as follows [1] Seems sh_offset is missing? That is what readelf prints as Off > [17] .rela.text RELA 0000000000000000 071423 001728 18 > 1 4 8 The offset of rela text should have been aligned, but it is not. Can you report a bug on icc? As a work around using the gnu assembler if possible

https://bugs.freedesktop.org/show_bug.cgi?id=105977 Bug ID: 105977 Summary: Samsung screen replacement in a Dell laptop brings corrupted display Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium

Is the program being built by gcc or clang? Cheers, Rafael Rafael Avila de Espindola <rafael.espindola at gmail.com> writes: > Martin Richtarsky via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Hi, >> >> for programs linked with lld it's substantially slower to get callstacks >> in gdb, in comparison to gold-linked programs. Two measurements:

Hi Martin, It's hard to tell what is wrong only with the information. If that is an open-source program, can you give me a link to that so that I can try? If that's a proprietary software you cannot share with me, you might want to produce small reproducible test case. On Thu, Mar 23, 2017 at 1:10 AM, Martin Richtarsky <s at martinien.de> wrote: > Hi Rui, > > fyi I'm

Compilers don't know about functions that are not defined in the same compilation unit, so they leave call instruction operands as zero (because they can't compute any absolute nor relative address of the destinations), and let linkers fix the address by binary patching. So, what you are seeing is likely a bug of LLD that it fails to fix the address for some reason. Can you dump that

> Please try it out, run tests, build your favourite projects and file > bugs about anything that needs to be fixed, marking them as blockers > of http://llvm.org/pr31622. I have encountered very long compile times for three large source files containing generated/unrolled code at -O1. We are talking about 10+ hours here without completing, so it looks very much like an endless loop. The

Hi llvm-community, I use llc (3.4-final) to generate object file: *llc code.bc -mtriple=x86_64-pc-win32-elf -mcpu=x86-64 -filetype=obj -code-model=large -o=code.o* then I load it with *RuntimeDyld + SectionMemoryManager* in my app. I faced the problem described in 15356 <http://llvm.org/bugs/show_bug.cgi?id=15356>bug. Debug assertion fails at

It is my pleasure to announce that LLVM 3.6 is now available! Get it here: http://llvm.org/releases/ This release contains the work of the LLVM community over the past six months: many many bug fixes, optimization improvements, support for more proposed C++1z features in Clang, better native Windows compatibility, embedding LLVM IR in native object files, Go bindings, and more. For details, see

It is my pleasure to announce that LLVM 3.6 is now available! Get it here: http://llvm.org/releases/ This release contains the work of the LLVM community over the past six months: many many bug fixes, optimization improvements, support for more proposed C++1z features in Clang, better native Windows compatibility, embedding LLVM IR in native object files, Go bindings, and more. For details, see

On Wed, Mar 15, 2017 at 2:22 PM, Martin Richtarsky <s at martinien.de> wrote: > Here is the relevant output: > > 0000000000013832 <func()>: > 13832: 55 push %rbp > 13833: 48 89 e5 mov %rsp,%rbp > 13836: 53 push %rbx > 13837: 48 83 ec 18 sub $0x18,%rsp

Martin Richtarsky <s at martinien.de> writes: > Rafael Avila de Espindola wrote : >>> Maybe gdb needs to fall back to slower line number resolution because >>> e.g. >>> low and high bounds cannot be retrieved and debug_line_address is 0? >> >> It is hard to know without a reproducible. I tried gdb on clang itself >> build with both clang and

Martin Richtarsky <s at martinien.de> writes: > Hi, > >> Is the program being built by gcc or clang? > gcc 6, but I can try clang. > >> Are both using --gdb-index? Can you try lld trunk if so? > No. > >> Is any of the programs you tested open source? > No. > > Here is some more info. I enabled "set verbose on" in gdb. With this >