similar to: [LLVMdev] Detrimental optimization for reducing relocations.

> So, clearly the optimization is making things worse. Would it be okay to delete > this code and eliminate the isBaseAddressKnownZero? I would like to get rid of > it. I think it is OK. I can see ld/gdb expecting a relocation, but if that is the case we should just have a flag saying it is needed. If you are really motivated to check it, run the gdb testsuite with your patch, but on

----- Original Message ---- > From: Rafael Ávila de Espíndola <rafael.espindola at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Thu, March 10, 2011 4:22:32 PM > Subject: Re: [LLVMdev] Detrimental optimization for reducing relocations. > > > So, clearly the optimization is making things worse. Would it be okay to >delete > > this code and eliminate the

> From: Rafael Ávila de Espíndola <rafael.espindola at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Thu, March 10, 2011 4:22:32 PM > Subject: Re: [LLVMdev] Detrimental optimization for reducing relocations. > > > So, clearly the optimization is making things worse. Would it be okay to >delete > > this code and eliminate the isBaseAddressKnownZero? I would

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

Change the assembly code to use the new _ASM_MOVABS macro which get a symbol reference while being PIE compatible. Adapt the relocation tool to ignore 32-bit Xen code. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier <thgarnie at google.com> --- arch/x86/tools/relocs.c | 16

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

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

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

On 28.04.23 11:50, Hou Wenlong wrote: > Similar to the alternative patching, use relative reference for original > instruction rather than absolute one, which saves 8 bytes for one entry > on x86_64. And it could generate R_X86_64_PC32 relocation instead of > R_X86_64_64 relocation, which also reduces relocation metadata on > relocatable builds. And the alignment could be hard

Currently llvm-dwarfdump isn't very useful on ELF .o files because it doesn't apply relocations. nlewycky at ducttape:~$ llvm-dwarfdump helloworld.o | grep debug_str\\[ 0x0000000c: DW_AT_producer [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)") 0x00000012: DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk

On 2020-11-14, Alexander Yermolovich wrote: >Thanks for doing a diff and asking in other groups. > >So if I understand your concern with using first reloc as it relates to .debug_str. > >In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some

> -----Original Message----- > From: Fāng-ruì Sòng <maskray at google.com> > Sent: Tuesday, November 17, 2020 1:51 AM > To: Alexander Yermolovich <ayermolo at fb.com> > Cc: David Blaikie <dblaikie at gmail.com>; Wenlei He <wenlei at fb.com>; llvm- > dev at lists.llvm.org; Robinson, Paul <paul.robinson at sony.com>; James > Henderson

Thanks for feedback. I agree with patch and numbers this will be a more concrete discussion, but I wanted to judge overall receptiveness to this approach and see maybe there was a better way. "Whilst the majority of objects will only have a single CU in them, there will be exceptions (LTO-generated objects, -r merged objects etc), so we do need to consider this approach." David can you

On Sun, May 31, 2020 at 9:57 AM Fangrui Song <maskray at google.com> wrote: > > > On 2020-05-30, David Blaikie wrote: > >On Sat, May 30, 2020 at 8:50 PM Fangrui Song <maskray at google.com> wrote: > >> > >> On 2020-05-29, David Blaikie wrote: > >> >On Fri, May 29, 2020 at 2:20 PM Robinson, Paul <paul.robinson at sony.com> wrote: >

> Subject: Re: [llvm-dev] Range lists, zero-length functions, linker gc > > On 2020-05-28, David Blaikie wrote: > >On Thu, May 28, 2020 at 2:52 PM Robinson, Paul <paul.robinson at sony.com> > >wrote: > > > >> As has been mentioned elsewhere, Sony generally fixes up references > from > >> debug info to stripped functions (of any length) using

> Will the testsuite work on ELF? The patch does not make any functional change > for the other formats. I know that gdb is okay with the example, but that > doesn't say very much. The patch is probably OK then. The gdb testsuite works with clang on ELF. There used to be a lot of silly failures like it not expecting clang warnings, but I think most of the current ones are real.

I found out today that Google Chrome is now available for Linux. However, and this is a big but: $ sudo rpm -ivh google-chrome-beta_current_x86_64.rpm Password: warning: google-chrome-beta_current_x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 7fac5991 error: Failed dependencies: lsb >= 3.2 is needed by google-chrome-beta-4.0.249.30-33928.x86_64 xdg-utils is needed by