search for: thunk

Displaying 20 results from an estimated 417 matches for "thunk".

Did you mean: think
2017 Jan 04
5
RFC: LLD range extension thunks
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...
2017 Jan 05
2
RFC: LLD range extension thunks
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...
2017 Jan 06
3
RFC: LLD range extension thunks
...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...
2017 Jan 06
2
RFC: LLD range extension thunks
...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...
2016 Jun 22
2
[LLD] thunk implementation correctness depends on order of input section.
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...
2016 Jun 21
2
[LLD] thunk implementation correctness depends on order of input section.
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...
2017 Apr 04
2
[LLD] RFC Range Thunks Implementation review for ARM and Mips
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...
2016 Sep 07
5
[LLD] Writing thunks before the corresponding section
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...
2016 Nov 29
2
[LLD] Writing thunks before the corresponding section
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 Th...
2004 Sep 22
1
Problem compiling Corel-WINE
...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...
2017 Jan 18
4
RFC: LLD range extension thunks
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 too...
2016 Nov 30
0
[LLD] Writing thunks before the corresponding section
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. > I...
2011 Jan 31
3
[LLVMdev] Compile function with limited set of registers? Jump to another function?
...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:...
2011 Jan 31
0
[LLVMdev] Compile function with limited set of registers? Jump to another function?
...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...
2018 Feb 03
4
retpoline mitigation and 6.0
...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 guaran...
2018 Feb 03
2
retpoline mitigation and 6.0
...; > > > 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...
2011 Feb 02
1
[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 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...
2011 Jan 31
1
[LLVMdev] Fw: Compile function with limited set of registers? Jump to another function?
...;>> >>>>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. >>>> >>>&g...
2014 Oct 09
2
[LLVMdev] PSA: Perfectly forwarding thunks can now be expressed in LLVM IR with musttail and varargs
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)...
2018 Feb 03
0
retpoline mitigation and 6.0
...o 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 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 each thunk is that it is identical i...