Dynamic libraries, again

[Walter Bright]

Jacob Carlborg wrote:
> On 3/15/10 20:36, Walter Bright wrote:
>> Jacob Carlborg wrote:
>>> On 3/15/10 19:50, Walter Bright wrote:
>>>> 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 beg and end sections are not in the dynamic library.
>>
>> That doesn't make sense, because they are in the .o files
>> (you can verify this with dumpobj). Did you generate a map file
>> for the .so?
> 
> They are in the object files but not in the dynamic library. I verified 
> that with dumpobj.

Perhaps that's related to the linker errors.

> 
>>> But it's possible to get the data with out those globals. This is how:
>>> http://tango.pastebin.com/YbmyZksx . This will also pull in all the
>>> module infos from the dynamic libraries regardless if they are used or
>>> not. BTW these globals are just causing trouble.
>>
>> How do they cause trouble, especially if they aren't even in the shared
>> library?
> 
> 1. They are globals
> 2. They cause linker errors when building dynamic libraries which 
> requires workarounds
> 3. They're not put into the dynamic libraries as they should


I don't understand. What kind of linker errors?


>>>> 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.
>>>
>>> I think this is the problem with the __deh_eh section. I don't know
>>> from where I should get the __deh_eh section, the executable, the
>>> dynamic library or both. If both, how would I do that?
>>
>> As I wrote, if you have a shared library, it will have its own deh
>> section that
>> is completely distinct from the application's. The reason is because the
>> linker
>> doesn't know what dynamic libraries will be loaded, so there's no way it
>> can
>> combine the deh sections. I don't think the runtime loader is capable of
>> doing
>> a link. Therefore, the exception handling code will have to search 
>> *both*.
>>
>> To do both, the shared library will have to 'register' its deh code with
>> the
>> application code that searches deh, so the application code will know 
>> there
>> is another deh to search.
>>
>> Either that, or the application code will have to do a runtime search
>> for all
>> loaded deh sections.
> 
> I will try this now. Does the order matter?

No.