Fragile ABI

[Paulo Pinto]

On Saturday, 18 August 2012 at 01:06:10 UTC, Michel Fortin wrote:
> On 2012-08-17 20:49:21 +0000, "Paulo Pinto" 
> <pjmlp at progtools.org> said:
>
>> On Friday, 17 August 2012 at 17:42:24 UTC, Michel Fortin wrote:
>>> Quote from <http://xenophilia.org/winvunix.html>:
>>> 
>>>> In Unix, a shared object (.so) file contains code to be used 
>>>> by the program, and also the names of functions and data 
>>>> that it expects to find in the program. When the file is 
>>>> joined to the program, all references to those functions and 
>>>> data in the file's code are changed to point to the actual 
>>>> locations in the program where the functions and data are 
>>>> placed in memory. This is basically a link operation.
>>>> In Windows, a dynamic-link library (.dll) file has no 
>>>> dangling references. Instead, an access to functions or data 
>>>> goes through a lookup table. So the DLL code does not have 
>>>> to be fixed up at runtime to refer to the program's memory; 
>>>> instead, the code already uses the DLL's lookup table, and 
>>>> the lookup table is modified at runtime to point to the 
>>>> functions and data.
>> 
>> For this just looks at two different ways to implement dynamic 
>> loading.
>> 
>> Having Windows experience since the Windows 3.1 days, 
>> alongside with
>> many other OS besides the typical Linux fan, I always find sad 
>> this vision
>> of Linux == UNIX, right, Windows wrong.
>
> I never intended to mean Windows == wrong. What I am saying is 
> that Windows does not have a dynamic linker capable of changing 
> pointers to symbols in the code it loads (which is what a 
> linker does). Code compiled for Windows need instead to refer 
> to a separate lookup table when accessing symbols from others 
> DLLs. Neither approach is wrong; each has different tradeoffs.
>
> Implementing a non-fragile ABI would be possible using a lookup 
> table of runtime calculated values for field and vtable 
> offsets, and those could be implemented both through a dynamic 
> linker with DLLs, but accessing the lookup table adds some 
> runtime overhead each time you need to access this symbol in 
> the code because of the indirection.
>
> In the original linked article (which I wrote) what was 
> proposed was to have the dynamic linker calculate offsets for 
> fields and vtable entries and insert those offsets directly in 
> the code (just like a linker does when it resolves symbols). 
> But for that you'd need a custom linker (both static and 
> dynamic), and probably a custom shared library format. So it's 
> a huge task, especially when you consider that it should run on 
> multiple platforms. But this same approach could make the C++ 
> ABI non-fragile too.

Wouldn't DLL redirection with Toolhelp32 help here?

But you're right the main problem is the portability across OS,
specially since most tend to have a C like linker, instead of a 
more
intelligent one.

This is can only be improved with higher level linkers, which is a
bit what happens with the solutions where the binaries have 
bytecode
which is only compiled at load time, like .NET and JVM in their 
default offerings. Or even older Lillith system, or Native Oberon 
with bytecode modules.

So, a solution would be either something as you describe, or 
having everyone use a D based OS. :)

--
Paulo