oh, ok. actually, I had partly considered this approach at one point, but opted with the form I did instead (in large part because it does not involve such a tweak, or dependency on the previous location). of course, as noted, due to the possibility of function pointers, this is a little risky. I had not considered this issue previously, but it is definitely worth consideration... I guess the issue then is how likely and how often a function will be replaced... it does lead to a possible idea though: use of an inter-module jump table. in this way, the actual usage of any external functions involves jumping through such a table (either directly, or by by making use of an implicit jump). sad issue though: this could incure a possibly noticable performance overhead (for normal calls, 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 such... ccMakeMovable(char *func); //an explicit call to the VM __movable void foo(int x) { //do something... } even more interestingly: if the same compiler were also used for static compilation, it could be used as a special feature to make such dynamic movability available even for statically compiled and linked code (as is, in my case, parts of the app which are statically compiled and linked, can't currently be relinked...). (even more cool: it does not necessarily imply a runtime dependency, since the stub and proxy variable would be merely passive elements, it could still be possible to compile and link the code apart from the VM, nevermind that any such proxy stubs would be useless though...). absent special compiler support, this could be implemented more manually with an existing compiler, such as gcc. example convention: int Afsd875gSd57g8Th(int x) //invisible autogen name { //do something } int (*__proxy_foo)(int x)=&Afsd875gSd57g8Th; int foo(int x) { return(__proxy_foo); } or (assembler): section .data __proxy_foo dd Afsd875gSd57g8Th section .text Afsd875gSd57g8Th: push ebp mov ebp, esp .. pop ebp ret foo: jmp [__proxy_foo] or such... ----- Original Message ----- From: Gordon Henriksen To: LLVM Developers Mailing List Sent: Wednesday, October 24, 2007 9:26 AM Subject: Re: [LLVMdev] me being stupid: me vs the llvm codebase... 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 the address of the function has been taken. LLVM's present approach is general. — Gordon ------------------------------------------------------------------------------ _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071024/0cd9f787/attachment.html>
On Wed, 24 Oct 2007, BGB wrote:> even more interestingly: if the same compiler were also used for static > compilation, it could be used as a special feature to make such dynamic > movability available even for statically compiled and linked code (as > is, in my case, parts of the app which are statically compiled and > linked, can't currently be relinked...).LLVM handles function pointers currently. It just overwrites the first instruction of the old code with an unconditional branch to the new implementation. Thus, any code branching to the old location will still work. It would be possible to implement more aggressive solutions, and if you are interested, llvmdev is a great place to talk about how to do it. Are you interested in using LLVM for your project? If not, llvmdev isn't a very appropriate place to talk about your project. If you are, this is a great place to ask questions or discuss design issues of LLVM itself. -Chris -- http://nondot.org/sabre/ http://llvm.org/
----- Original Message ----- From: "Chris Lattner" <sabre at nondot.org> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Wednesday, October 24, 2007 11:30 AM Subject: Re: [LLVMdev] me being stupid: me vs the llvm codebase...> On Wed, 24 Oct 2007, BGB wrote: >> even more interestingly: if the same compiler were also used for static >> compilation, it could be used as a special feature to make such dynamic >> movability available even for statically compiled and linked code (as >> is, in my case, parts of the app which are statically compiled and >> linked, can't currently be relinked...). > > LLVM handles function pointers currently. It just overwrites the first > instruction of the old code with an unconditional branch to the new > implementation. Thus, any code branching to the old location will still > work. >yes, that works so long as one has write access to the text section (or the code is otherwise in a writable area). at least with typical compilation, afaik this is not the case (I think both linux and windows by default have .text being read only, which may limit applicability of this approach...). so, nearly any option works for dynamic land, but fewer options are around for static linking (this is partly what I was addressing as well, that in some cases one makes available a "universal proxy", and the VM is smart enough to figure this out, for example, by first trying to adjust the proxy before falling back to more drastic measures, such as patching or relinking...).> It would be possible to implement more aggressive solutions, and if you > are interested, llvmdev is a great place to talk about how to do it. >yes, maybe. well, maybe I can fammiliarize myself with the project more, and maybe be able to say something actually useful at some point...> Are you interested in using LLVM for your project? If not, llvmdev isn't > a very appropriate place to talk about your project. If you are, this is > a great place to ask questions or discuss design issues of LLVM itself. >I am still undecided mostly. a major detractor at this point for me and LLVM, is that it is written in C++, and I am not so good with C++, and I am otherwise not so fammiliar with the codebase... (as for myself and my project, well, my issue is partly one of isolation, namely that not really anyone cares about much of this, so I don't have all that many people to talk to...). (not too much interesting goes on on usenet is all...). well, this is among other issues, like homework, lack of female interest, and 'future'... so, I am just some lame hobbyist is all I guess, may stay around or may go away, or may use LLVM or continue using my own compiler (and at some point have to get a job or something, parents want me to be a school teacher, but I had hoped to be a programmer, maybe games or 3D modeling software or something, but they think there is no future in this, or that there is too much competition and no real jobs, or such...). this is life I guess...> -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Apparently Analagous Threads
- [LLVMdev] me being stupid: me vs the llvm codebase...
- [LLVMdev] me being stupid: me vs the llvm codebase...
- [LLVMdev] me being stupid: me vs the llvm codebase...
- [LLVMdev] me being stupid: me vs the llvm codebase...
- [LLVMdev] me being stupid: me vs the llvm codebase...