Fragile ABI

Michel Fortin michel.fortin at michelf.ca
Fri Aug 17 18:06:10 PDT 2012


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.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/



More information about the Digitalmars-d mailing list