similar to: [LLVMdev] Compile function with limited set of registers? Jump to another function?

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

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

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

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

hi, i also have problems compiling llvm-gcc (current svn version). llvm is current llvm svn. i tried to use every gcc version from 4.0 to 4.3 to compile llvm-gcc. i configured llvm-gcc like this (and tried every other combination of disable-shared, disable-multilib and bootstrap) : ../llvm-gcc/configure --prefix=/usr --enable-llvm=/usr --enable-languages=c,c++ --disable-shared

Hi, Jack! On Fri, Nov 2, 2012 at 6:18 PM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > Nick, > Have you noticed that llvm/clang svn produces the following linker > warnings on > 'make check-all'? > > Linking CXX executable Debug/AsanTest > ld: warning: direct access in > llvm::convertible_fwd_ostream::~convertible_fwd_ostream() to global weak >

Nick, Have you noticed that llvm/clang svn produces the following linker warnings on 'make check-all'? Linking CXX executable Debug/AsanTest ld: warning: direct access in llvm::convertible_fwd_ostream::~convertible_fwd_ostream() to global weak symbol vtable for llvm::convertible_fwd_ostream means the weak symbol cannot be overridden at runtime. This was likely caused by different

I haven't read the all the emails in full detail, but it seems pretty clear that __x86_indirect_thunk and __llvm_retpoline_push do not do the same things. It sounds like __llvm_retpoline_push is equivalent to __x86_indirect_thunk except first it swaps the two words on the top of the stack. I arranged it this way because the x86 call instruction puts the intended return address on the top of

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

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

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

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

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

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

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

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

Verifying a report I just got pinged about, building vanilla openssh 7.7p1 on linux configures ok, but fails build around 'retpoline' I've started looking through recent reports; haven't _yet_ found anything similar. While I continue, is any of the following familiar/expected? Either known bug/issue or env conflict? The current env includes supposedly retpoline-ready GCC 8.1.1,

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

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