Dynamic libraries, again

[Jacob Carlborg]

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. 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.

> 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.

> 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?

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

dumpobj works fine with executables and shared libraries.