similar to: [RFC][LLVM] New Constant type for representing function PLT entries

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

On Aug 24, 2020, at 6:47 PM, Leonard Chan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Thanks for the responses! I’m going to see if I can summarize the concerns and ideas people have (for my own clarity) and see where we can go on from there. Folks seem to be on board with the idea of introducing some new IR entity that (after linking) *could* be a reference into the PLT, but some

> -----Original Message----- > From: Fāng-ruì Sòng <maskray at google.com> > Sent: Friday, August 21, 2020 4:04 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: Leonard Chan <leonardchan at google.com>; llvm-dev at lists.llvm.org > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for > representing function PLT entries > > On Fri, Aug

On 8/21/20 1:34 AM, Renato Golin via llvm-dev wrote: > +1 to Eric's point. We could get into a state where we must get the > relocation right in the IR to get a good (or worse, any) lowering. > > I'd rather have a canonical representation, relocation friendly, that > we try to keep and back ends know how to lower well. > > --renato FWIW, I think that we all agree

Hi all. Are there any thoughts on the new name idea ("dso_local_stub" or "dso_local_unnamed_stub")? I'd like to see if I can move forward with my patch. On Tue, Sep 1, 2020 at 11:01 AM Leonard Chan <leonardchan at google.com> wrote: > I see. Perhaps something like "dso_local_stub" or "dso_local_unnamed_stub" > would be better naming? The

IIUC, the actual requirements for the proposed pltentry(@X) constant is: 1. The returned address MUST have a constant offset at link-time from some other unspecified but defined-in-the-same-binary/DSO symbol Y. Which symbol it is is presumed not to matter because all locally-defined symbols have constant offsets from each-other, anyhow. 2. The address is otherwise insignificant. (Therefore, coming

> -----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 Aug 29, 2020, at 6:53 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> Sorry for the delay responding Leonard. I don’t really understand your rationale here. A PLT entry is a completely target specific concept because some targets don’t have PLTs. I don’t think there is any reason that a frontend would abstractly generate this unless they already have a

Hi, I wanted to see if there was a way in IR to emit a local alias such that I would get: ``` .type _ZTVSt13bad_exception, at object # @_ZTVSt13bad_exception .globl _ZTVSt13bad_exception _ZTVSt13bad_exception: *.L_ZTVSt13bad_exception:* .long 0 # 0x0 .long (_ZTISt13bad_exception.rtti_proxy-.L_ZTVSt13bad_exception)-8 .long

On 22 August 2018 at 04:27, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > However, if you pass the -emit-relocs option to the linker, lld keeps all > relocations that have already been resolved in an output executable. By > analyzing a relocation table in a resulting executable, you could find all > locations where the ifunc PLT is called. Then, you can

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

Here is a demonstration of behaviour that is probably an optimization by someone far smarter than me that did not anticipate anyone wanting to do this, but for my purposes it looks more like a bug than a feature. I have tested this with R2.6.2 on Windows, no additional packages loaded (beyond the default), I have tested using the default graphics object, pdf, jpeg, and cairoDevice (ok I loaded a

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

In the context of support not only IFunc but DTrace, what kind of features do you want to add to lld, if you have a chance to implement it in the linker instead of a post-processing tool? I wonder if we can solve both of your problems. On Thu, Aug 23, 2018 at 1:33 AM Mark Johnston <markj at freebsd.org> wrote: > On Wed, Aug 22, 2018 at 10:11:00AM -0400, Ed Maste wrote: > > On 22

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

I'm not very familiar with relocations but your fix looks the same as ARMTargetLowering::LowerCall, so from that perspective it lgtm (but I may be missing something). On Wed, Aug 21, 2013 at 8:04 AM, Logan Chien <tzuhsiang.chien at gmail.com>wrote: > Hi Anton and JF, > > Thanks for your review. After reading the source code more carefully, I > have come up with a

Hi Anton and JF, Thanks for your review. After reading the source code more carefully, I have come up with a different way fix this issue. We can simply resolve this issue by adding ARMII::MO_PLT flags with MachineInstrBuilder in FastISel pass (without failing back to DAG lowering). The new patch is attached, and the test case is not changed. Sorry for your inconvenience. Please have a

On Wed, Aug 26, 2015 at 03:53:33PM -0400, Rafael Espíndola wrote: > > I'm not sure if this would be sufficient. The R_ARM_JUMP24 relocation > > on ARM has specific semantics to implement ARM/Thumb interworking; see > > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf > > Note that R_ARM_CALL has the same operation but different semantics.

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() {

> 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