December 14, 2011
On 12/14/2011 2:39 AM, Martin Nowak wrote:
> I don't think that this belongs in the current release if that's what you meant.
>
> So far I haven't found any regressions with these changes.
> One part I'm not positive about is setting the size of public data symbols
> to the DT size.
> I also just found another issue with runtime relocations and EH so there will
> be a little more in this direction but if you don't see any issues with the
> data symbols we might as well merge it sooner than later.

I would like you to be confident that the changes are correct :-)

December 14, 2011
On Wed, 14 Dec 2011 11:51:13 +0100, Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/14/2011 2:17 AM, Martin Nowak wrote:
>>> If the compiler generated static constructors and destructors ala C++ that
>>> would then be used to register the sections, that could hook into the existing
>>> C++ support code and not require special linker scripts and special object files.
>>
>> I partly agree and will give that approach another try.
>> The huge drawback is that a shared library is self-contained w.r.t.
>> module construction, TLS and EH. When doing this on a per object base
>> the overhead increases with the number of linked objects and guaranteeing
>> ordered initialization becomes non-trivial.
>
> Yeah, I thought of that after I posted it.

I think I finally found a feasible solution.
It is possible to create a section group consisting of
a constructor/destructor referencing entries in .ctors/.dtors
and probably related data. The will be treated as one combined
COMDAT and subsequently get merged to a unique instance of each.
3 4 5 6 7 8 9 10 11 12 13
Next ›   Last »