4 ms·
There is no technical limitation why it is impossible in C, however the raw details of how C is implemented make it entirely impractical. A super generalized d
by uxp 8y ago
There is no technical limitation why it is impossible in C, however the raw details of how C is implemented make it entirely impractical.
A super generalized description of a C function might check if a register contains a positive value. If so, it will then jump to address 0x42, which is a memory offset, which is the beginning of another function. Its near impossible to "swap" out what lies at 0x42 since that was defined at compile time and is included in a monolithic executable.
Looking at more dynamic languages, like C#, Java or LISP, they run on a virtual or abstracted machine instead of raw registers. This means that a similarly defined function will instead jump to whatever matches the requirement. That means that we could have a lookup table that says we should jump to a symbol of S42, and based on what we have loaded in memory, S42 resides at 0x42. Essentially, all functions are function pointers, and we can change the value the resides in that memory address in order to swap out implementations of whatever function maintains the same signature as the intended function. This is why one can make trivial changes to C# in visual studio while stopped at a breakpoint and have those changes applied to the running program. Instead of jumping to 0x42, we jump to 0x84 by "hotswapping" the value of the pointer we're about to jump into.
Obviously this isn't entirely the truth, there are a lot more nuances and it's a fair bit more complicated than this, but the idea should hold water.
- lisper 8y ago> There is no technical limitation why it is impossible in C, Yes, there is. You can't trace the stack in portable C, so you can't build a proper garbage collector.
- jstimpfle 8y agoDebugging a function and GC are independent things. Also, you can easily add tracing information since you will know how the C code is being run. There is no good reason not to. There are easy ways to build a GC in portable C as well, of course, if less performant. As you will know, in portable C you cannot even implement a system call. So what?
- lisper 8y ago> Debugging a function and GC are independent things. Yes, but redefining a function and GC are not. > There are easy ways to build a GC in portable C as well, of course, if less performant. No, because you can't walk the stack. Also pointer aliasing. [UPDATE] I just realized that I was wrong about redefining functions in C. Not only is it possible, you can actually do it with currently available technology using dynamically linked libraries. But I have never seen anyone actually do this (which is why it didn't occur to me).
- jstimpfle 8y ago> But I have never seen anyone actually do this (which is why it didn't occur to me). I wrote about this in my two earlier comments. This is very old technology. And very commonly used. I think most plugin systems wrap dynamically linked libraries. This is also an easy way to redefine functions without needing GC. Under the hood, it is implemented in the loader's way: virtual memory pages mapped as read-only and executable (see mmap() or mprotect() for example).
- jstimpfle 8y agoYour point is moot. C doesn't "run on raw registers". That's just common practice but has nothing to do with C per se. You can easily run it on the C#'s virtual machine. Furthermore, it doesn't matter whether you are running on a virtual machine or on bare metal. What matters is if you have turned on optimizations (such as hardcoding of function addresses, or even code inlining) that remove flexibility (such as hot swapping of code). Visual Studio can hot-edit C code as well. And as I stated, it is pretty easy and common practice to hot swap object code through DLLs or shared objects even on less high-tech platforms. It's easily done with function pointers (as you described) and a simple API (GetProcAddress() on Windows, dlsym() on Linux). Why shouldn't it be possible in C? Virtual Machines bring portable executables and nothing more, I think. Well, maybe a slightly nicer platform for co-existence and interoperability of multiple programming languages (but then again, there is considerable lock-in to the platform).