search for: thunking

I'm about to start working on range extension thunks in lld. This is an attempt to summarize the approach I'd like to take and what the impact will be on lld outside of thunks. I'm interested if anyone has any constraints the approach will break, alternative suggestions, or is working on something I'll need to take account of? I expect range extension thunks to be important for

Hello Rui, Thanks for the comments - Synthetic sections and rewriting relocations I think that this would definitely be worth trying. It should remove the need for thunks to be represented in the core data structures, and would allow . It would also mean that we wouldn't have to associate symbols with thunks as the relocations would directly target the thunks. ARM interworking makes reusing

On Fri, Jan 6, 2017 at 6:21 AM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jan 5, 2017 at 8:15 PM, Peter Smith <peter.smith at linaro.org> > wrote: > >> Hello Rui, >> >> Thanks for the comments >> >> - Synthetic sections and rewriting relocations >> I think that this would definitely be worth trying. It should

After looking at this for a while, I do not think that this problem is NP-hard. With a finite "short branch" displacement k, I was not able to come up with a gadget that could create global constraints as would be needed to e.g. model an instance of 3SAT or vertex cover in terms of this problem. The problem is hard though. I believe that it is likely to be exponential in the "short

First of all thanks for finding the bug. I agree with Rui that right now we can manage without general thunk infrastructure. Let's provide at least a few "thunk" implementation and after that reconsider necessity of common thunk framework. As to MIPS there is one more type of thunk (keyword is .MIPS.stubs) and one more optimization of current thunk (putting a thunk in the beginning

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

This RFC is primarily to support the review of the range extension thunks implementation of lld. This concerns ARM and Mips as all of the thunk creation step is skipped over if the target doesn't need thunks. Mips LA25 Thunks are not range extension Thunks but these are generated using the same code, I've kept the behaviour the same as it is now, although the implementation is obviously

Hi, MIPS LA25 thunk is used to call PIC function from non-PIC code. Usually it contains three instructions: lui $25, %hi(func) addiu $25, $25, %lo(func) j func We can write such thunk in an arbitrary place of the generated file. But if a PIC function requires the thunk is the first routine in a section, we can optimize the code and escape jump instruction. To do so we just write the

Hi, Sorry for delay with reply. It looks like now thunks can be implemented as a synthetic sections. In that case we give flexible solution and will be able to put thunks before/after related sections, using different alignment etc. As far as I know BFD linker uses the same approach at least for MIPS thunks. I will try to implement this idea. On Thu, Sep 8, 2016 at 1:44 AM, Rui Ueyama <ruiu

In reference to an old posting: we managed to get a copy of the final CVS Corel-WINE code. I am trying to compile it with GCC-3.3.4. I realize that this might not work as I had to hunt down three patches on Google to build GLibc-2.3.1 with that GCC version. NOTE: for those that don't know, GLibc-2.3.1 is the last version of GLibc that Corel-WINE will work with. So, I was building

On Jan 19, 2017 2:48 AM, "Ed Maste" <emaste at freebsd.org> wrote: On 4 January 2017 at 13:34, Peter Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I'm about to start working on range extension thunks in lld. This is > an attempt to summarize the approach I'd like to take and what the > impact will be on lld outside of thunks. Now that LLD works

Sure. One thing I want to remind you is that there is a place in Writer.cpp where we assume all synthetic sections were appended to end of Sections list. Look for `llvm::reverse`. If you add synthetic section thunks right before/after non-synthetic sections, you also want to change that. On Tue, Nov 29, 2016 at 1:18 PM, Simon Atanasyan <simon at atanasyan.com> wrote: > Hi, > >

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27464147-1968795515-1164715405=:5670 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT You need to re-install packages when you update R, as it says in the rw-FAQ. Use update.packages(checkBuilt=TRUE) to

Hi James, I see the problem now. You might look at VMKit (a Java VM build with the LLVM JIT compiler) - I would expect it uses a similar method for resolving interface calls (the method, if I understand it correctly, is well-known in the Java world). I've CC'd the main dev behind VMKit - he might be able to lend some insight. --Joshua On Mon, Jan 31, 2011 at 2:24 PM, James Williams

Thanks, that's a good idea - I'll have a look through the VMKit source. -- James On 31 January 2011 21:39, Joshua Warner <joshuawarner32 at gmail.com> wrote: > Hi James, > > I see the problem now. You might look at VMKit (a Java VM build with the > LLVM JIT compiler) - I would expect it uses a similar method for resolving > interface calls (the method, if I

...t, clear flag is really best, and we've very publicly documented this technique as 'retpoline'. But the GCC community has a fairly different design AFAICT... The only embedded thunks the offer are inline (ours are always out-of-line, even if they aren't external). Also, they support thunking indirect branches that we don't: ret. Our feature really is oriented around exposing the retpoline mitigation, and I don't think there is any demand for the complexity that would be entailed by generalizing it further. But I'm sure the GCC folks have a very reasonably different perspect...

On Fri, Feb 2, 2018 at 4:36 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Sat, 2018-02-03 at 00:23 +0000, Chandler Carruth wrote: > > > > Two aspects to this... > > > > One, we're somewhat reluctant to guarantee an ABI here. At least I > > am. While we don't *expect* rampant divergence here, I don't want > > this to become

Hi James, Joshua is right, what you're trying to accomplish is quite known in the Java VM world ( http://domino.research.ibm.com/comm/research_people.nsf/pages/dgrove.oopsla01.html ). In order to express the "thunk" code in LLVM you need a full control of how registers are used (because otherwise they would mess up with the arguments). I haven't investigated enough to know if

Forgot to cc the list. > >----- Forwarded Message ---- >From: Samuel Crow <samuraileumas at yahoo.com> >To: James Williams <junk at giantblob.com> >Sent: Mon, January 31, 2011 4:27:45 PM >Subject: Re: [LLVMdev] Compile function with limited set of registers? Jump to >another function? > > >Hi James, > > >If you're looking for a way to

On 8 Oct 2014, at 18:19, Reid Kleckner <rnk at google.com> wrote: > The one target I know about where varargs are passed differently from normal arguments is aarch64-apple-ios/macosx. After thinking a bit more, I think this forwarding thunk representation works fine even on that target. Typically a forwarding thunk is called indirectly, or at least through a bitcast, so the LLVM IR call