similar to: lld mishandling R_X86_64_PC32 relocations

Hi Guys, Thanks for the interest in the xen hypervisor debugger, prev known as kdb. Btw. I''m gonna rename it to xdb for xen-debugger or hdb for hypervisor debugger. KDB is confusing people with linux kdb debugger and I often get emails where people think they need to apply linux kdb patch also... Anyways, attaching patch that is cleaned up of my debug code that I accidentally left in

> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Fangrui > Song via llvm-dev > Sent: Thursday, August 20, 2020 10:18 PM > To: Leonard Chan <leonardchan at google.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for > representing function PLT

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

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

linux fedora f9 x86_64 llvm-2.4 I tried building a bunch of my python modules (which compile to shared libraries) using llvm-c++ instead of gnu c++. When the program runs, I see these messages: python: Symbol `__gxx_personality_v0' causes overflow in R_X86_64_PC32 relocation Ideas?

I'm rebuilding the centosplus kernel with ISA P&P and ISA some devies enabled. At the very end of compilation, I got a lot of error messages that looked like: Error: ./init/initramfs.o .text refers to 0000046e R_386_PC32 .init.text Error: ./init/initramfs.o .text refers to 0000059c R_386_PC32 .init.text Error: ./init/initramfs.o .text refers to 000007a8 R_386_PC32

On Thu, Jan 22, 2015 at 11:54 AM, Richard Smith <richard at metafoo.co.uk> wrote: > On Thu, Jan 22, 2015 at 4:35 AM, H.J. Lu <hjl.tools at gmail.com> wrote: >> Here is the link: >> >> https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 > > The document contains this claim (as do many other psABI documents): > > "Bit-fields that are neither

I do have concerns about the amount of object level modeling that we want to do in the IR though. While it isn't the highest level IR we've managed to mostly avoid these kinds of features/complications in the past. I'm definitely interested in hearing some alternate implementations here and there rather than a full set of constants for relocations. Keeping the IR abstract enough over

Hi, I'm in the process of migrating from clang5 to clang10. Unfortunately clang10 introduced a negative performance impact. The cause is an increase of PLT entries from this patch (first released in clang7): https://bugs.llvm.org/show_bug.cgi?id=36370 https://reviews.llvm.org/D43383 If I revert that clang patch locally, the additional PLT entries and the performance impact disappear. This

Hello, I'm enabling clang LTO to improve code size of Uefi standard (http://www.uefi.org/) firmware (https://github.com/tianocore/edk2), which is mostly C code. My project is in https://github.com/shijunjing/edk2 branch llvm : https://github.com/shijunjing/edk2/tree/llvm. I find my most firmware modules work well after enable LTO, but some X64 modules will not run (e.g. hang with CPU

Compilation failure on c/s 17194 is as follows: /root/randy/vtd-stage/xen/common/built_in.o: In function `guest_remove_page'': /root/randy/vtd-stage/xen/common/memory.c:172: undefined reference to `__bitop_bad_size'' /root/randy/vtd-stage/xen/common/memory.c:172: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__bitop_bad_size''

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

ELF that MCJIT writes on x86_64 has relocations in it. Particularly, R_X86_64_PC32 relocations are used for the sections .gcc_except_table and .eh_frame related to exception processing. I am not sure where is general documentation on relocation types, including R_X86_64_PC32. Looks like it's nowhere to be found on the web. But 32-bit relocation can't be used in 64-bit code since it

The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. #include <stdio.h> int main() { fputs("hi\n", stdout); } The reason is that stdout gets a R_X86_64_PC32 relocation, but is of type Object. The ELF writer can't see this, and assumes all R_X86_64_PC32 relocations in dynamic outputs are to functions

Hi! Using the following extlinux.conf serial 0x2f8 57600 0x013 # that is, RTS/CTS flow control on COM2 prompt 1 timeout 100 say Select 'linux' or 'xen'. say Automatically booting 'xen' in 10 seconds. default xen label linux kernel /vmlinuz-2.6.18-6-686 append initrd=/initrd.img-2.6.18-6-686 root=/dev/mapper/xen1-root ro console=tty0 console=ttyS1,57600n8r noresume

On February 11, 2016 11:30:02 PM PST, poma <pomidorabelisima at gmail.com> wrote: >... >http://repo.or.cz/syslinux.git/commit/8750016 > >Booting from DVD/CD... > >ISOLINUX 6.04 ETCD >and then hangs > >ttyS0 debug shows single line: >_malloc(24, 0, 2) @ 0x00104bab = > > >$ ld --version >GNU ld version 2.26.20160125 >... >$ gcc --version >gcc

On 07/08/2011 01:25 PM, Yuri wrote: > ELF that MCJIT writes on x86_64 has relocations in it. Particularly, > R_X86_64_PC32 relocations are used for the sections .gcc_except_table > and .eh_frame related to exception processing. > I am not sure where is general documentation on relocation types, > including R_X86_64_PC32. Looks like it's nowhere to be found on the web. > But

On 9/23/2013 7:07 PM, Nick Kledzik wrote: > On Sep 23, 2013, at 4:52 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. >> >> #include <stdio.h> >> >> int main() { >> fputs("hi\n", stdout); >>

Here is the link: https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 -- H.J.

Linux GABI [1] introduced new .note.gnu.property section which contains a program property note which describes special handling requirements for linker and run-time loader. LLD does not support .note.gnu.property yet. GABI specifies 2 types of entries: GNU_PROPERTY_STACK_SIZE and GNU_PROPERTY_NO_COPY_ON_PROTECTED: * GNU_PROPERTY_STACK_SIZE: Its pr_data field contains an integer in the format