Dynamic libraries, again

[Walter Bright]

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.