search for: relink

From: "Xiaowei.Hu" <xiaowei.hu at oracle.com> ocfs2_block_group_alloc_discontig() disables chain relink by setting ac->ac_allow_chain_relink = 0 because it grabs clusters from multiple cluster groups. It doesn't keep the credits for all chain relink,but ocfs2_claim_suballoc_bits overrides this in this call trace: ocfs2_block_group_claim_bits()->ocfs2_claim_clusters()-> __ocfs2_claim_clus...

Hi Assuming I had an application stub based on (say) lli, and I'd like to allow a hypothetical IDE to recompile and relink a function: Is that supported in any way currently? Assuming actually patching all call sites to point to the newly generated function is possible, I guess what I need is to be able to either track or find all of the call sites. The trickiest bit seems to be if the function that's being redefi...

On Oct 23, 2007, at 18:19, BGB wrote: > On Oct 23, 2007, at 11:45, Gordon Henriksen wrote: > >> Generally speaking, LLVM neither helps nor hinders here. Maybe >> someone will follow up with whether the JIT uses stub functions >> which would enable dynamic relinking If not, it would be a >> straightforward, if platform-specific, feature to add. > > I don't use proxy or stub functions, I relink them... I misspoke. See here: http://llvm.org/doxygen/classllvm_1_1JIT.html#a7 Relinking the function as you describe is risky in the case that t...

/bin/sh ../../mkinstalldirs /sw/lib/xmms/Input ../../libtool-disable-static --mode=install /usr/bin/install -c libxmms-flac.la /sw/lib/xmms/Input/libxmms-flac.la libtool-disable-static: install: warning: relinking `libxmms-flac.la' cd /Users/glenn/Desktop/flac-1.0.5_beta1/src/plugin_xmms; /bin/sh ../../libtool-disable-static --mode=relink gcc -I../.. -I./include -I../../include -g -O2 -O3 -DNDEBUG -Dunix -fomit-frame-pointer -funroll-loops -finline-functions -Wall -W -Winline -DFLaC__INLINE=__inli...

Couldn’t you write the relocations to the ELF executable? I don’t know if current linkers have support for this, but it seems possible in theory to make a relinkable executable. If you want to do this with an already linked executable though, then yea this won’t be possible. On Fri, Jul 20, 2018 at 10:30 AM Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Typically people do this kind of thing by writing a loader for the > ex...

...R=/tmp (to simulate building into a deb file) The xmms plugin build fails with: mkdir /tmp/sw/lib/xmms mkdir /tmp/sw/lib/xmms/Input ../../libtool-disable-static --mode=install /usr/bin/install -c libxmms-flac.la /tmp/sw/lib/xmms/Input/libxmms-flac.la libtool-disable-static: install: warning: relinking `libxmms-flac.la' cd /Users/ben/Desktop/flac-1_0_2-src_0/flac-1.0.2/src/plugin_xmms; /bin/sh ../../libtool-disable-static --mode=relink gcc -I../.. -I./include -I ../../include -Wall -W -O3 -DNDEBUG -fomit-frame-pointer -funroll-loops -finline-functions -Winline -DFLaC__INLINE=__inline__...

...but it could make moving functions really cheap). a more selective way of doing this would be helpful (for example, a special compiler-specific keyword, or some other approach for telling the VM/linker that a particular function is movable). this would probably one-off the function, by forcibly relinking it as a proxy to the function (any future attempts at relinking the function then simply adjust its associated pointer). potentially, this could also be made the default behavior for when relinking functions (if they are being forcibly relinked, well, assume they are being made movable). or su...

...2) Load (compile) IR modules into Object code and cache the objects. 3) Upon running finalize (link) everything and run. 4) If a function is changed, kill its module and reload it. Then use the cached objects and finalize everything. Compared with the JIT, 4) isn't scalable, since it requires relinking of possibly many modules due to the change of just one function. I wonder if it's possible to use the stub function mechanism in order to save the relinking step. The dynamic linker can resolve everything to the stub functions that jump to real functions but then the function implementatio...

...ror I would rather not have the misfortune of dealing with (much less trying to make it think it was something like lisp or python...). > as a result, my compiler generally refrains from inlining things or > doing brittle inter-function optimizations (after all, one could > potentially relink parts of the image and break things...). < It's possible to use LLVM in the same manner by simply refraining from the use of inter-procedural optimizations. > possibly, yes. < If LLVM bytecode is used as the on-disk representation, however, LLVM would allow the use of offline optim...

...the proper equivalent library with the proper syscalls in MacOS and Windows). So, the question: Is it "currently possible" (by "currently possible" I mean that all the needed tools/code already exist) to somehow "unlink" the code and data from the ELF executable, and relink it as two new executables: one Mach-O and another PE? Would this be possible with just LLVM tools, or would other libraries/tools also be needed? Thanks a lot! ardi

LLVM, When we recompile, is it possible to "make" only one of the tools, or at least relink only the tools whose object files have changed? Thanks Dave

...R modules into Object code and cache the objects. > 3) Upon running finalize (link) everything and run. > 4) If a function is changed, kill its module and reload it. Then use the cached objects and finalize everything. > > Compared with the JIT, 4) isn't scalable, since it requires relinking of possibly many modules due to the change of just one function. > > I wonder if it's possible to use the stub function mechanism in order to save the relinking step. The dynamic linker can resolve everything to the stub functions that jump to real functions but then the function imp...

--- Ben Hines <bhines@alumni.ucsd.edu> wrote: > I guess the problem is really why is it trying to relink it? > > The "parse error: condition expected:" is suspicious, though.. maybe > it's another "zsh as sh" problem... hmm.. I don't remember having any trouble building the plugin on my ibook but that was a few months ago, so my memory may be fuzzy. I'll tr...

...pendencies in a single > monolithic module, that is, if it can be avoided > > I hope to use Linker::linkModules but this is always destructive. That is ok for > one module depending on a single one, since if that one changed, is no big deal, > but isn't it overkill to rebuild and relink N-1 modules that did not change just > because of a single one that changed? > > I wonder if there is a non-destructive version of linkModules that can work for > JIT execution. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at c...

...t you would execute some >functions using the JIT then, later, those functions will be modified and thus >need to be re-jitted? > >Ciao, Duncan. Hi Duncan, that is exactly it. My hope is to keep the need for rebuild isolated to the individual modules where the modifications occur, and relink appropiately. I've discussed this with people that have worked on llvm frontends before, and they suggest that this would require keeping copies of all the modules around, rebuild the modules that changed, and then relink everything into a single static fat module that the JIT can use, which...

...`libtool --finish /sw/lib'". The xmms plugin now gives a different error: /bin/sh ../../mkinstalldirs /tmp/sw/lib/xmms/Input ../../libtool-disable-static --mode=install /usr/bin/install -c libxmms-flac.la /tmp/sw/lib/xmms/Input/libxmms-flac.la libtool-disable-static: install: warning: relinking `libxmms-flac.la' cd /Users/ben/Desktop/flac-1_0_2-src_1/flac-1.0.2/src/plugin_xmms; /bin/sh ../../libtool-disable-static --mode=relink gcc -I../.. -I./include -I ../../include -Wall -W -O3 -DNDEBUG -fomit-frame-pointer -funroll-loops -finline-functions -Winline -DFLaC__INLINE=__inline__...

--- Ben Hines <bhines@alumni.ucsd.edu> wrote: > At 10:39 AM -0700 5/21/02, Josh Coalson wrote: > >--- Ben Hines <bhines@alumni.ucsd.edu> wrote: > >> I guess the problem is really why is it trying to relink it? > >> > >> The "parse error: condition expected:" is suspicious, though.. > maybe > >> it's another "zsh as sh" problem... hmm.. > > > >I don't remember having any trouble building the plugin on > >my ibook but that wa...

...de and cache the objects. > > 3) Upon running finalize (link) everything and run. > > 4) If a function is changed, kill its module and reload it. Then use the > cached objects and finalize everything. > > > > Compared with the JIT, 4) isn't scalable, since it requires relinking of > possibly many modules due to the change of just one function. > > > > I wonder if it's possible to use the stub function mechanism in order to > save the relinking step. The dynamic linker can resolve everything to the > stub functions that jump to real functions b...

...e `demo()' for some demos, `help()' for on-line help, or `help.start()' for a HTML browser interface to help. Type `q()' to quit R. [Previously saved workspace restored] /var/tmp/R-1.7.1/bin/R.bin: /var/tmp/R-1.7.1/library/ts/libs/ts.so : WARNING: symbol(FortEntries) size mismatch relink your program /var/tmp/R-1.7.1/bin/R.bin: /var/tmp/R-1.7.1/library/ts/libs/ts.so : WARNING: symbol(CallEntries) size mismatch relink your program /var/tmp/R-1.7.1/bin/R.bin: /var/tmp/R-1.7.1/library/ts/libs/ts.so : WARNING: symbol(CEntries) size mismatch relink your program > search() [1] "....

Hi, JIT does not allow functions to call others in different modules, so all modules need to be statically linked in a big fat module. If a module needs to be recompiled, all the others need to as well as relinked. there are two ways i intend to approach this problem: 1) forget about JITing, build each module into a .bc, call gcc to generate .soname libraries, dynamically load with dlopen() those libraries 2) keep the modules unlinked, and when execution is required, link the required dependencies into...