forwardcom forum

Once again.. once again you are ignoring the most important points and I have to repeat myself: Most important of all, you said "WILL SUPPORT" dllopen, ergo dynamic linking will be an option, it will be used and must be designed and optimized. Fragmentation is inevitable. Flat sequences of...

It's frustratingly difficult to find any serious research comparing the two. In the meantime, you're still not acknowledging that static linking huge graphical libraries is unacceptable, this is an obvious case where the functions and transitive dependencies are large and massively shared across man...

Alright, I see the need to take the static vs dynamic linking debate from the top. In the first place, this is still frequently debated, to give my conclusion upfront, I'm not in favor of imposing a decision one way or another. My opinion here is the compiler should maintain a database of functions ...

"only a very small fraction of (DLLs) them are actually used". This is remedied by splitting them. The aspect of this project I appreciate the most is its uncompromising nature: For the most part I can really believe in the longevity of the solutions presented. And then.. here it is insist...

"A module is what comes from an object file. A library can contain multiple modules, each containing a function." This definition isn't very rigorous and still unclear. I wasn't talking about static linking, which is rather standard but not exactly a good solution, known to bloat programs ...

'Module' doesn't match much in the manual The idea to relink each function and all their transitive dependencies dynamically is potentially very expensive, especially as compared to the almost free copying in of libraries; Granted this wastes some memory but I take that over complicated CPU intensiv...

It appears that partially copying library functions quickly becomes difficult as soon as any of them depend on each other. As a quick example; `f = .. ; g = f ; h = f;` If you want to use only 'h', due to relative offsets you are probably forced to copy g since selectively copying and relinking only...

Nice
It would also allow pushing vector registers without needing to carry around their size separately

I don't know if it makes sense at the hardware level, but the common dynamic array push operation wants to do a bounds check either immediately before or after the write.

"Multi-entrypoint functions are possible in assembly code, but cannot be coded in high level language" This is obviously dependent on the high level language. In any event languages are more likely to want to do this automatically. Partially compatible libraries with multiple versions of t...

Let's re-examine the question from the top: Suppose I am an object that requires 'malloc'. The Elf solution to this is for the object to list all libraries that may contain the imported symbols (DT_NEEDED), then have relocations either to PLT or to text with eager binding and relocate-readonly enabl...

[redundant text removed] I'm not disputing that copying only the parts of a library used into memory can sometimes improve the caching and theoretically with the kernel's help even bypass the mmap tables (This really needs to be measured though as sharing also sounds optimal in many cases), but even...

Resolving names can take an unacceptable amount of time, and are one of the reasons linking happens lazily on linux, leading to read+executable PLT sections etc.. Mangled names can be huge and the standard technique will always do at least one full strcmp. It seems desirable to eagerly bind all symb...