search for: backpatch

...pilation strategy can always enforce the use of a stub for calls into jitted functions. I think you said what I was going to say, but here's how I see it: getPointerToFunction always returns the address of the stub, so any indirect calls to the function hit the stub. The stub will attempt to backpatch the callsite, and should fail if it is a) outside the JIT or b) an indirect call. Indirect calls will always go through the stub. Direct calls can be backpatched. Alternatively, everything would go through the stub. Finally, you have to be careful about the memory model of the architecture you...

...nforce the use of a stub for calls into jitted functions. > > I think you said what I was going to say, but here's how I see it: > > getPointerToFunction always returns the address of the stub, so any > indirect calls to the function hit the stub. The stub will attempt to > backpatch the callsite, and should fail if it is a) outside the JIT or > b) an indirect call. Indirect calls will always go through the stub. > Direct calls can be backpatched. > > Alternatively, everything would go through the stub. > > Finally, you have to be careful about the memory m...

...calls into jitted functions. > > > > I think you said what I was going to say, but here's how I see it: > > > > getPointerToFunction always returns the address of the stub, so any > > indirect calls to the function hit the stub. The stub will attempt to > > backpatch the callsite, and should fail if it is a) outside the JIT or > > b) an indirect call. Indirect calls will always go through the stub. > > Direct calls can be backpatched. > > > > Alternatively, everything would go through the stub. > > > > Finally, you have to b...

...pose we had a means of tagging certain calls (and maybe branches) as explicitly requiring relocations. Any back-patchable call would have a relocation in the generated code, and the MC-JIT would be aware of the location and type of the relocations, and rt-dyld would handle the upfront resolution. Backpatching, then, is just a matter of updating the resolution for a given symbol, and asking rt-dyld to re-link the executable code. Thoughts? --Owen

> > > Then we would always have the location of the br B instruction in A, as it is pushed onto the stack or saved in link register when A calls B. > Right, unless you wanted to go with direct calls in the JIT. I don't know that inspecting a running program's stack for return values while compiling on a separate thread is sane :) That said, the adaptive compilation

On Thu, Mar 31, 2011 at 11:07 PM, Eric Christopher <echristo at apple.com>wrote: > > > > > > No we will always have control over where the parent calls the functions > that we are recompiling. As explained in the example below > > > > Original Code > > > > Binary for A: Binary for B: > > > > ... ...

All, I have a CentOS 4 system I need to update OpenSSH on. Most of my experience has been on slackware and I am new to using yum and packages. I ran yum and it tells me that my current installed version is 3.9 patch level 1. It also said that there are no updates for it. I did a google for it but every link I saw that seemed to point to info about an rpm for 4.3 came up not found. Is there a

Hi all, I updated the patches to remove the native object wrapper format. As suggested we will work on getting the ThinLTO framework in place using bitcode first, and then work on adding the native object support. As noted in this RFC and in the associated patch D11722, for now I have empty ThinLTO blocks with no records, since I wanted to get feedback on the overall block design first. The RFC

On Apr 3, 2011, at 12:01 PM, Xin Tong Utoronto wrote: > Another way to do the patching is to first atomically inserted a self-loop jump -2 atomically (jump -2 takes 2 bytes and 2 bytes writing is atomic on x86 ) into the old branch address on x86 such that it stops all threads reaching this point. copy in the new compiled function address. and then re-patch the jump -2 with the correct

Hello all, For the past couple of weeks I have been spending some time debugging a couple of issues I was having with Mongrel when I put load on it. I have seen two distinct issues: 1. Mongrel stopped responding as if in an endless loop. 2. Mongrel crashed when severely loaded. I believe to have resolved these two issues and have attached patches which shows the resolution (simple as it is).

...ISO8859-1 The problem is easy to pinpoint (a network sniffer helped me a little there, and then a nice debugger). At one point in processing input commands, smbclient >= 2.2.1 thinks it has a DOS-translated name, but this is wrong. And thus accented characters are improperly translated. I backpatched to Samba 2.2.0, since several people told me they did not have this kind of problem. And it's true :-) The 'core' of my grudge seems to lie in the new clistr_push function, which does not exist in release 2.2.0. A 'cd directory' command is thus processed by cli_chkpath, whi...

Hi all, Using R a as a real-time application called by Php for a website, I would like to run one R process only, which would manage user connections. For the time each user who asks for an analysis causes a new R process to start, which is not suitable in prevision of many users. R needs about 30 seconds to run the script which makes the analysis. The problem is that this waiting time is n

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

Hi All, In the interests of improving visibility into ORC JIT development I'm going to try writing weekly status updates for the community. I hope they will provide insight into the design and state of development of LLVM's JIT APIs, as well as serving as a convenient space for discussions among LLVM's large and growing community of JIT API users. The length and detail will vary

...if the set of "somewhat stable" C APIs > doesn't provide all the possible features, though. > > It's easy enough to add a bunch of wrappers or ifdefs hiding some simple > signature changes, e.g. LLVMOrcGetSymbolAddress adding a parameter as > happened in LLVM 6, but backpatching support for a larger API redesigns, > into stable versions, is scary. We do however quickly get complaints if > a supported version cannot be compiled due to dependencies, as people > tend to upgrade their OS separately from e.g. their database major > version. > > > > (...

...of tagging certain calls (and maybe branches) as > explicitly requiring relocations. Any back-patchable call would have a > relocation in the generated code, and the MC-JIT would be aware of the > location and type of the relocations, and rt-dyld would handle the upfront > resolution. Backpatching, then, is just a matter of updating the resolution > for a given symbol, and asking rt-dyld to re-link the executable code. > > Thoughts? > > --Owen > > > > ------------------------------ > > _______________________________________________ > LLVMdev mailing li...