Dynamic libraries, again

[Jacob Carlborg]

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?
>
>> 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?
>
>
>
>>> 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!
>>
>> I've already figured that out. I'm pretty sure the ModuleInfo array is
>> working.
>>
>>> 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.
>>
>> This is the problem. I did the same with __deh_eh as with __minfodata
>> (see the link above) but it doesn't work.
>
> Does your code look in the deh for both the application and the shared
> library?
>
>
>>> 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.
>
>
>>> Yes, dumpobj knows about .o files, but it doesn't know about linked
>>> files.
>>
>> dumpobj works fine with executables and shared libraries.
>
> I've never tried that.

I managed to get it to work now. I had to reverse the order of the 
module info array in object_.d and the function table array in deh.d. 
Thank you very much for all the help.