Am Tue, 23 Apr 2013 17:10:43 +0200 schrieb "Iain Buclaw" <ibuc...@ubuntu.com>:
> In reference to this link: > http://forum.dlang.org/post/50476c77.20...@googlemail.com > > > I'm currently working on dealing with each of these issues in the > following pull (with the intention to merge back upstream where > required). > https://github.com/D-Programming-GDC/GDC/pull/62 > I'll make sure to have a look at this, but as always too little time... > In order: > > 1. ClassInfo > > The initialiser emitted will have two symbols, one public symbol > with the TypeInfo_Class members, and a second private generated > symbol for the interfaces array. I can't forsee any way this > could break compatibility with any existing compilied gdc (or > perhaps even dmd/ldc) binaries out there. Sounds good. That should also be good for debug info. > > > 2. TypeInfoStruct > > Likewise to the above. The situation here is a little different AFAIR. TypeInfoStruct has no interfaces array or something similar, it only had a variable size because the name data was part of the TypeInfoStruct type. Now name is just stored as a slice and the data is stored in a custom symbol. So the TypeInfoStruct size is fixed and there's no need to do anything special about it. https://github.com/D-Programming-Language/dmd/pull/1128/files > > > 3. ModuleInfo > > We can get the correct type as is defined in object.di through > Module::moduleinfo, this would mean that all generated moduleinfo > symbols will be the same size (rather than be of a variable size) > padded out with zeros at the end. However, this requires a > front-end patch to store it as there is an implementation > conflict because of MODULEINFO_IS_STRUCT macro, the type is a > StructDeclaration (Module::moduleinfo is a ClassDeclaration type). > > Going one step further, the type itself could probably be put up > for a clean up. Removing the struct New/Old implementation > (keeping the 'New' for getting data members) and perhaps replace > it something like the following. > > struct ModuleInfo > { > uint flags; // Module flags > uint index; // Index into moduleinfo array > void*[14] reserved; // Padding large enough to contain > // all optional data added depending on > flags. > } > > This however is not really required, but am just throughing it > out there as a thought. ModuleInfo could really need a cleanup, sounds good. > > > Any thoughts on this? (Looking at you Johannes). > > Regards > Iain Everything sounds good so far. As far as I can tell the workarounds we implemented some time ago work fine, but it would certainly be good to implement the proper fixes. Maybe we can revert some of this code after this fix: git log --grep=fsection-anchors
