|Posted by Walter Bright|
in reply to Johannes Pfau
Posted in reply to Johannes Pfau
These changes sound worthwhile.
On 9/5/2012 8:15 AM, Johannes Pfau wrote:
> I had some more time to investigate gdc's issue #120, the problem which
> prevents gdc from working properly on ARM without disabling certain
> optimization flags. I found a way to work-around the issue in the
> backend, but it leads to lots of code duplication. And the duplicated
> code must be kept in sync with code in the DMD frontend, so I think this
> issue really needs to be fixed in the DMD frontend.
> Here's the gdc backend hack for reference (excluding the
> ModuleInfo/TypeInfo fixes which requires duplicating the genmoduleinfo
> function): https://github.com/jpf91/GDC/commits/fix120
> The problem always occurs if a variable declarations type size is
> smaller than it's initializer size. In theory setting the type size to
> the same size as the initializer is enough to make it work on ARM. But
> there's a problem: In the cases where this issue occurs the type size is
> not static and must be calculated. For the ModuleInfo example the
> calculation code is quite long (genmoduleinfo) and we'd have to
> duplicate that code and keep it in sync. Also simply adjusting the type
> size doesn't fix the missing debug info.
> So these are the cases where this problems occurs and what I think would
> be the proper fixes, would be great to get some feedback on this:
> static arrays when the initializer is smaller than the array
> GCC can't deal with different element sizes in one array. DMD adds the
> padding at the
> end of the array as one big element, which causes issues for gdc. This
> can be fixed
> easily in gdc, but the fix could also be applied to the upstream DMD
> frontend as it
> shouldn't cause problems for dmd/ldc either.
> The ClassInfo is always typed as object_.d/TypeInfo_Class but the
> initializer is set to TypeInfo_Class + a static array of struct
> Interface + a static array of function pointers (vtable entries). This
> extra data is used for the "Interface interfaces" member in
> In ClassDeclaration::toObjFile the interfaces array (
> https://github.com/jpf91/GDC/blob/fix120/gcc/d/dfrontend/toobj.c#L640 )
> is currently referenced using dtxoff (
> https://github.com/jpf91/GDC/blob/fix120/gcc/d/dfrontend/toobj.c#L552 ).
> Is there a specific reason to implement it like this?
> Can we change it to output a own symbol for the interfaces array(module
> scope), then make the symbol static so it has no visible name outside of
> the object file and then reference it? This would not only fix the arm
> bugs, it also allows to put out proper debug information for this
> interfaces array.
> The remaining vtable pointer array should get it's own static symbol as
> well. (Or probably the interfaces array and the vtable
> array(s) should be combined into one struct which should get it's own
> static symbol?)
> This is typed as the TypeInfo struct in object_.d, but the initializer
> additionally contains the name data of the struct. See
> TypeInfoStructDeclaration::toDt (
> https://github.com/jpf91/GDC/blob/fix120/gcc/d/dfrontend/typinf.c#L714 ).
> Can we use a own static symbol for the name?
> (probably more TypeInfo is affected, I'll have to check this)
> This seems to be the most difficult part. It has no common type at all,
> the size always differs. GDC currently types it as object, althought
> it's a struct...
> It would be great if we could create a StructDeclaration/VarDeclaration
> for it and use the same code paths that are used for all
> StructDeclarations instead of the Module::genmoduleinfo(
> https://github.com/jpf91/GDC/blob/fix120/gcc/d/dfrontend/toobj.c#L53 )
> function. We probably want to somehow avoid the TypeInfo for this struct
dmd-internals mailing list