search for: pltentri

Hi all, We would like to propose a new Constant type in LLVM for representing entries in the Procedure Linkage Table (PLT). The PLT is a data structure used for dispatching position-independent function calls to appropriate functions where the address of the function is not known statically. Right now, if a call is made to a function, it may be lowered to a direct call to the function itself or

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

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

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

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

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