search for: thunk

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

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 thunks more difficult as not every thunk is compatible with every call...

...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 remove >> the need for thunks to be represented in the core data structures, and >> would allow . >> > > Creating symbols for thunks would have another benefit: it makes > disassembled output easier to read because thunks have names. > > >> It would also mean that we wouldn't have to associ...

...te: >>> >>>> 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 . >>>> >>> >>> Creating symbols for thunks would have another benefit: it makes >>> disassembled output easier to read because thunks have names. >>> >>> >&gt...

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 of the se...

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

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

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

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

...f GLibc that Corel-WINE will work with. So, I was building Corel-WINE CVS against GLibc-2.3.1 with GCC-3.3.4 and I get this error: /usr/local/gcc-3.3.4/bin/gcc -c -march=i586 -O2 -Wall -fPIC -D__WINE__ -D_REENTRANT -DSHELL_NO_DESKTOP -I. -I. -I../include -I../include -I/usr/X11R6/include -o thunk.o thunk.c thunk.c:365:47: pasting "." and "PeekMessageA" does not give a valid preprocessing token thunk.c:366:47: pasting "." and "PeekMessageW" does not give a valid preprocessing token thunk.c:367:45: pasting "." and "GetMessageA" doe...

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 well for FreeBSD/amd64 (and arm64 is very close) I'm looking at other architectures, starting with mips64. The statically-linked toolcha...

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, > > Sorry for delay with reply. > > It looks like now thunks can be implemented as a synthetic sections. > In th...

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

...s Williams <junk at giantblob.com> wrote: > Hi Joshua, > > Thanks - I was hoping that would be the case. > > However, I've had a think about this since I posted to the list and I > believe the only way to handle these issues safely in LLVM IR would be to > define the thunk as varargs. I'm not sure how well LLVM handles varargs but > ideally it would all compile down to nothing since the parameters to the the > thunk would be in the same registers/stack locations as required by the > target method. > > Unfortunately, varargs has some downsides: ther...

...b.com>wrote: > >> Hi Joshua, >> >> Thanks - I was hoping that would be the case. >> >> However, I've had a think about this since I posted to the list and I >> believe the only way to handle these issues safely in LLVM IR would be to >> define the thunk as varargs. I'm not sure how well LLVM handles varargs but >> ideally it would all compile down to nothing since the parameters to the the >> thunk would be in the same registers/stack locations as required by the >> target method. >> >> Unfortunately, varargs has...

...landed in r323155. Are we ready to > > merge this to 6.0, or are there any open issues that we're waiting > > for? Also, were there any followups I should know about? Also, > > release notes please :-) > > Eep, please can we keep the command line option for clang and the thunk > ABI matching what GCC, the Linux kernel and Xen are all doing? > > To say that I am not stunningly keen on > https://lkml.org/lkml/2018/2/2/975 would be a bit of an > understatement... Two aspects to this... One, we're somewhat reluctant to guarantee an ABI here. At least I...

...; > > > 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 something we cannot change if there are good reasons > > to do so. We've already changed the thunks once based on feedback > > (putting LFENCE after the PAUSE). > > Surely adding the lfence was changing your implementation, not the ABI? > > And if we really are talking about the *ABI* not the implementation, > I'm not sure I understand your concern. > > The ABI for...

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 that's possible today in LLVM (I think it wasn't a few years ago when I added the optimization). So what I ended up wi...

...;>> >>>>Thanks - I was hoping that would be the case. >>>> >>>>However, I've had a think about this since I posted to the list and I believe >>>>the only way to handle these issues safely in LLVM IR would be to define the >>>>thunk as varargs. I'm not sure how well LLVM handles varargs but ideally it >>>>would all compile down to nothing since the parameters to the the thunk would >>>>be in the same registers/stack locations as required by the target method. >>>> >>>>Un...

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 site would look like: MIPS also has some subtle (and annoying) differences between variadic and non-variadic function calls. Most notably (o32-only)...