Dynamic libraries, again

[Walter Bright]

Jacob Carlborg wrote:
> Latest update:
> I've found the __minfodata section and the content looks fine. The new 
> problem I have is that an exception is thrown in _moduleCtor2 and I 
> can't catch the exception. The problem is that it can't find any handler 
> table. I think it's something wrong with _deh_beg and _deh_end in the 
> deh module.
> 
> If I have the _deh_beg and _deh_end as globals (as they are by default) 
> it doesn't find a handler table. If I instead get the __deh_beg and the 
> __deh_end sections from the main executable it does find a table handler 
> but the table looks very different compared to a statically linked 
> Tango. The length of the table is close to 600 compared to 1 when Tango 
> is statically linked. It also contains a lot of zeros.

Here's how things work. For each module, a reference to that module's ModuleInfo instance
is stored in a segment named __minfodata. But, also, two empty segments are created:
__minfo_beg and __minfo_end. A symbol, _minfo_beg, is defined for section __minfo_beg,
and _minfo_end for __minfo_end. A "sandwich" is created:

segment __minfo_beg
     _minfo_beg is defined here

segment __minfodata
     ModuleInfo pointers go here

segment __minfo_end
     _minfo_end is defined here

The linker helpfully groups all the __minfodata segments together, and voila, by examining
&_minfo_beg and &_minfo_end, we know the beginning and end of the ModuleInfo array!

The exception handling tables, __deh_beg, __deh_eh, __deh_end are handled exactly the same
way. The code to generate these tables is in backend/machobj.c.


So, for an application, this all works great. The trouble with a shared library
is now there are two sets of these triples, and the runtime doesn't know about the
shared library set.

Yes, dumpobj knows about .o files, but it doesn't know about linked files.