similar to: Weak undefined symbols and dynamic libraries

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

> On Mar 4, 2016, at 2:48 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 29, 2016 at 1:53 PM, < <mailto:>> wrote: > @A_vtable = {i8*, i8*, i32, i32} {0, @A::rtti, @A::f - (@A_vtable + 16), @A::g - (@A_vtable + 16)} > > There's a subtlety about this aspect of the ABI that I should call attention to. The virtual function

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); > } > > The reason is that stdout gets a R_X86_64_PC32 relocation, but is

On Tue, Feb 26, 2019 at 6:41 PM Eli Friedman <efriedma at quicinc.com> wrote: > This seems like a very complicated approach… do you have some numbers to > give some idea how much of an improvement we’re talking about here over a > more conventional solution involving shared libraries? Or have you not > gotten that far? > I can talk to my internal customer to see what kind

Hello, I am currently facing an issue at linking stage when compiling basic C code for an embedded PPC32 platform and linking with LLD. For external symbol linkage LLVM appears to use PLT which results in generating a R_PPC_PLTREL24 relocation, that is not support by LDD. Therefore even such a basic example cannot be built: /* s.c */ int f() { return 0; } /* t.c */ int f(); int _start() {

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

Hal, I very well understand that LDD may not be in a good state for PPC32, and it would definitely need some improvements sooner or later. In fact I even submitted a patch adding a relocation to ldd just a few hours ago. However, this particular case is not related to LDD, it is a design issue and furthermore a regression in LLVM itself. I checked gcc, and neither does it try to use PLT and

I've been working on supporting ARM/Thumb interworking thunks in LLD and have encountered a limitation that I think it is worth bringing up in a wider context. This is all LLD specific, apologies if I've abused llvm-dev here. TL;DR summary: - Thunks in lld may not work if they are added to InputSections that have already been scanned. - There is a short term fix, but in the longer term I

Hi Rafael, Yes, merging gv prevents linker to do garbage collection. Should it be implemented as a peephole pass? If we do it too early, the distance between GVs are not fixed yet. PS: Below is the GCC output with "extern" hidden: ldr r2, .L2 stmfd sp!, {r3, lr} .save {r3, lr} .LPIC0: add r0, pc, r2 bl _Z4initPv(PLT) ldr r1, .L2+4 .LPIC1: add r0, pc, r1 bl _Z4initPv(PLT) ldr

On Fri, Mar 4, 2016 at 2:48 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Mon, Feb 29, 2016 at 1:53 PM, <> wrote: >> >> @A_vtable = {i8*, i8*, i32, i32} {0, @A::rtti, @A::f - (@A_vtable + 16), >> @A::g - (@A_vtable + 16)} >> > > There's a subtlety about this aspect of the ABI that I should call > attention to. The virtual function

> On Mar 7, 2016, at 4:22 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Mon, Mar 7, 2016 at 4:09 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote: >> On Mar 4, 2016, at 2:48 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> On Mon, Feb 29, 2016 at

Hello, Rafael > On linux X86_64, calls to local but externally visible functions > should use the PLT. Access to local (same compilation unit), variables > can just use RIP relative access. Right, this is just optimization. AFAIR, current code already does this for 'normal' PIC - it just checks for linkage and doesn't assemble call via PLT for stuff with internal linkage.

Hello. We found the following problem with MC JIT, on ARM it can't generate valid code for instruction "bl <external_function>" like: bl printf Because the ELF file in memory generated by MC JIT does not have the .plt section, but we need to have the following code to be emitted in it: .plt:00008290 STR LR, [SP,#-4]! .plt:00008294

On Sat, 2012-04-28 at 15:51 -0500, Hal Finkel wrote: > > > - There is no support for generating position-independent code on > > > PPC32. (PIC on PPC64 now works well). Nevertheless, I have > > > sometimes run into linking errors when compiling shared libraries > > > with C++ on PPC64. PPC64 is PIC by nature. As for the linking issue, possibly you blew the

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

On Tue, Sep 24, 2013 at 10:49:36AM -0500, Shankar Easwaran wrote: > Not sure why this is being done for a long time with the GNU linker. Because the main program is not PIC, it will only use absolute references to global symbols. For functions, you can create a PLT record, but for data access, you have to hide the real symbol and copy the content over to the equivalent in the main binary.

On Sep 23, 2013, at 7:05 PM, Shankar Easwaran wrote: > 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>

That change seems to fix things here. Thanks! -Gordon From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of JF Bastien Sent: Wednesday, August 21, 2013 12:53 PM To: Logan Chien Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Broken PLT on ARM from R183966 I'm not very familiar with relocations but your fix looks the same as

Hi all, I wanted to summarise some discussion on llvm-commits [0,1] as an RFC, as I felt it demanded wider circulation. Our support for references to absolute symbols is not very good. The symbol will be resolved accurately in non-PIC code, but suboptimally: the symbol reference cannot currently appear as the immediate operand of an instruction, and the code generator cannot make any assumptions

On Sep 24, 2013, at 9:13 AM, Joerg Sonnenberger wrote: > On Tue, Sep 24, 2013 at 10:49:36AM -0500, Shankar Easwaran wrote: >> Not sure why this is being done for a long time with the GNU linker. > > Because the main program is not PIC, it will only use absolute > references to global symbols. For functions, you can create a PLT > record, but for data access, you have to hide