D.gnu - Re: -fsection-anchors broken on ARM
- Iain Buclaw (40/40) Apr 23 2013 In reference to this link:
- Johannes Pfau (18/75) Apr 23 2013 I'll make sure to have a look at this, but as always too little time...
- Iain Buclaw (16/38) Apr 23 2013 Actually, found an interesting problem when confronting it.
- Iain Buclaw (14/54) Apr 24 2013 Or alternatively we could generate the type (for debugging) on the flyin...
- Iain Buclaw (23/78) May 08 2013 For the time being in this pull:
- Iain Buclaw (9/118) May 09 2013 Also, I have altered the mismatch check in d_finalize_symbol
- Johannes Pfau (4/134) May 11 2013 If it passes the testsuite then there is indeed no reason not to change
- Iain Buclaw (6/140) May 11 2013 If decl_initial size < type size. Then the backend will always
In reference to this link: http://forum.dlang.org/post/50476C77.20608 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 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. 2. TypeInfoStruct Likewise to the above. 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. Any thoughts on this? (Looking at you Johannes). Regards Iain
Apr 23 2013
Am Tue, 23 Apr 2013 17:10:43 +0200 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:In reference to this link: http://forum.dlang.org/post/50476C77.20608 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/62I'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/files3. 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 IainEverything 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
Apr 23 2013
Iain Buclaw <ibuclaw ubuntu.com> On 23 April 2013 17:28, Johannes Pfau <nospam example.com> wrote:Am Tue, 23 Apr 2013 17:10:43 +0200 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:Actually, found an interesting problem when confronting it. --- struct Interface { TypeInfo_Class classinfo; void*[] vtbl; ptrdiff_t offset; /// offset to Interface 'this' from Object 'this' <-- } --- I'll have to have a think about what value should be put there, and how best to put it in. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';In reference to this link: http://forum.dlang.org/post/50476C77.20608 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/62I'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.
Apr 23 2013
On 23 April 2013 18:25, Iain Buclaw <ibuclaw ubuntu.com> wrote:On 23 April 2013 17:28, Johannes Pfau <nospam example.com> wrote:Or alternatively we could generate the type (for debugging) on the flying in ::toSymbol 1. Module::toSymbol. Type = Type::moduleinfo type. 2. ClassDeclaration::toSymbol Type = Type::typeinfoclass type. Then for each interface, add the fields for Type::interface onto the type. 3. InterfaceDeclaration::toSymbol Likewise to above. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';Am Tue, 23 Apr 2013 17:10:43 +0200 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:Actually, found an interesting problem when confronting it. --- struct Interface { TypeInfo_Class classinfo; void*[] vtbl; ptrdiff_t offset; /// offset to Interface 'this' from Object 'this' <-- } --- I'll have to have a think about what value should be put there, and how best to put it in.In reference to this link: http://forum.dlang.org/post/50476C77.20608 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/62I'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.
Apr 24 2013
On 24 April 2013 15:12, Iain Buclaw <ibuclaw ubuntu.com> wrote:On 23 April 2013 18:25, Iain Buclaw <ibuclaw ubuntu.com> wrote:For the time being in this pull: https://github.com/D-Programming-GDC/GDC/pull/62 For ModuleInfo, TypeInfoClass and Interface classes, I have added a new kind of type node into the glue layer. - d_unknown_type_node: LANG_TYPE This means that the backend won't touch, or do any sort of laying out of the type. If we find this type in d_finalize_symbol (formerly called outdata), then we give it the compiler generated type of the initialiser, and for debug purposes give it an eponymous type name (eg: _Dobject_ModuleInfoZ symbol has type name struct _Dobject_ModuleInfoZ). This is fine for the workaround so far, but future improvements would be to take the logic from toObjFile / genmoduleinfo and give the fields the correct names when generating the symbol in toSymbol. Alternatively we could store this information within Symbol itself during the toObjFile / genmoduleinfo stage, and have d_finalize_symbol call a routine that will generate the correct type layout to prevent code duplication. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';On 23 April 2013 17:28, Johannes Pfau <nospam example.com> wrote:Or alternatively we could generate the type (for debugging) on the flying in ::toSymbol 1. Module::toSymbol. Type = Type::moduleinfo type. 2. ClassDeclaration::toSymbol Type = Type::typeinfoclass type. Then for each interface, add the fields for Type::interface onto the type. 3. InterfaceDeclaration::toSymbol Likewise to above.Am Tue, 23 Apr 2013 17:10:43 +0200 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:Actually, found an interesting problem when confronting it. --- struct Interface { TypeInfo_Class classinfo; void*[] vtbl; ptrdiff_t offset; /// offset to Interface 'this' from Object 'this' <-- } --- I'll have to have a think about what value should be put there, and how best to put it in.In reference to this link: http://forum.dlang.org/post/50476C77.20608 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/62I'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.
May 08 2013
On Wednesday, 8 May 2013 at 11:34:19 UTC, Iain Buclaw wrote:On 24 April 2013 15:12, Iain Buclaw <ibuclaw ubuntu.com> wrote:Also, I have altered the mismatch check in d_finalize_symbol (outdata) that you put in initially for this fix. Now it asserts that type_size == initialiser_type_size. This passes through the testsuite 100%, so I'll keep it. There should be no reason whatsoever why the initialiser would be less than the type size. Regards IainOn 23 April 2013 18:25, Iain Buclaw <ibuclaw ubuntu.com> wrote:For the time being in this pull: https://github.com/D-Programming-GDC/GDC/pull/62 For ModuleInfo, TypeInfoClass and Interface classes, I have added a new kind of type node into the glue layer. - d_unknown_type_node: LANG_TYPE This means that the backend won't touch, or do any sort of laying out of the type. If we find this type in d_finalize_symbol (formerly called outdata), then we give it the compiler generated type of the initialiser, and for debug purposes give it an eponymous type name (eg: _Dobject_ModuleInfoZ symbol has type name struct _Dobject_ModuleInfoZ). This is fine for the workaround so far, but future improvements would be to take the logic from toObjFile / genmoduleinfo and give the fields the correct names when generating the symbol in toSymbol. Alternatively we could store this information within Symbol itself during the toObjFile / genmoduleinfo stage, and have d_finalize_symbol call a routine that will generate the correct type layout to prevent code duplication.On 23 April 2013 17:28, Johannes Pfau <nospam example.com> wrote:Or alternatively we could generate the type (for debugging) on the flying in ::toSymbol 1. Module::toSymbol. Type = Type::moduleinfo type. 2. ClassDeclaration::toSymbol Type = Type::typeinfoclass type. Then for each interface, add the fields for Type::interface onto the type. 3. InterfaceDeclaration::toSymbol Likewise to above.Am Tue, 23 Apr 2013 17:10:43 +0200 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:Actually, found an interesting problem when confronting it. --- struct Interface { TypeInfo_Class classinfo; void*[] vtbl; ptrdiff_t offset; /// offset to Interface 'this' from Object 'this' <-- } --- I'll have to have a think about what value should be put there, and how best to put it in.In reference to this link: http://forum.dlang.org/post/50476C77.20608 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/62I'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.
May 09 2013
Am Thu, 09 May 2013 19:40:04 +0200 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:On Wednesday, 8 May 2013 at 11:34:19 UTC, Iain Buclaw wrote:If it passes the testsuite then there is indeed no reason not to change it. Not sure why I made it check for >= in the first place.On 24 April 2013 15:12, Iain Buclaw <ibuclaw ubuntu.com> wrote:Also, I have altered the mismatch check in d_finalize_symbol (outdata) that you put in initially for this fix. Now it asserts that type_size == initialiser_type_size. This passes through the testsuite 100%, so I'll keep it. There should be no reason whatsoever why the initialiser would be less than the type size.On 23 April 2013 18:25, Iain Buclaw <ibuclaw ubuntu.com> wrote:For the time being in this pull: https://github.com/D-Programming-GDC/GDC/pull/62 For ModuleInfo, TypeInfoClass and Interface classes, I have added a new kind of type node into the glue layer. - d_unknown_type_node: LANG_TYPE This means that the backend won't touch, or do any sort of laying out of the type. If we find this type in d_finalize_symbol (formerly called outdata), then we give it the compiler generated type of the initialiser, and for debug purposes give it an eponymous type name (eg: _Dobject_ModuleInfoZ symbol has type name struct _Dobject_ModuleInfoZ). This is fine for the workaround so far, but future improvements would be to take the logic from toObjFile / genmoduleinfo and give the fields the correct names when generating the symbol in toSymbol. Alternatively we could store this information within Symbol itself during the toObjFile / genmoduleinfo stage, and have d_finalize_symbol call a routine that will generate the correct type layout to prevent code duplication.On 23 April 2013 17:28, Johannes Pfau <nospam example.com> wrote:Or alternatively we could generate the type (for debugging) on the flying in ::toSymbol 1. Module::toSymbol. Type = Type::moduleinfo type. 2. ClassDeclaration::toSymbol Type = Type::typeinfoclass type. Then for each interface, add the fields for Type::interface onto the type. 3. InterfaceDeclaration::toSymbol Likewise to above.Am Tue, 23 Apr 2013 17:10:43 +0200 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:Actually, found an interesting problem when confronting it. --- struct Interface { TypeInfo_Class classinfo; void*[] vtbl; ptrdiff_t offset; /// offset to Interface 'this' from Object 'this' <-- } --- I'll have to have a think about what value should be put there, and how best to put it in.In reference to this link: http://forum.dlang.org/post/50476C77.20608 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/62I'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.
May 11 2013
On 11 May 2013 12:50, Johannes Pfau <nospam example.com> wrote:Am Thu, 09 May 2013 19:40:04 +0200 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:If decl_initial size < type size. Then the backend will always automatically pad out the end with zeroes. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';On Wednesday, 8 May 2013 at 11:34:19 UTC, Iain Buclaw wrote:If it passes the testsuite then there is indeed no reason not to change it. Not sure why I made it check for >= in the first place.On 24 April 2013 15:12, Iain Buclaw <ibuclaw ubuntu.com> wrote:Also, I have altered the mismatch check in d_finalize_symbol (outdata) that you put in initially for this fix. Now it asserts that type_size == initialiser_type_size. This passes through the testsuite 100%, so I'll keep it. There should be no reason whatsoever why the initialiser would be less than the type size.On 23 April 2013 18:25, Iain Buclaw <ibuclaw ubuntu.com> wrote:For the time being in this pull: https://github.com/D-Programming-GDC/GDC/pull/62 For ModuleInfo, TypeInfoClass and Interface classes, I have added a new kind of type node into the glue layer. - d_unknown_type_node: LANG_TYPE This means that the backend won't touch, or do any sort of laying out of the type. If we find this type in d_finalize_symbol (formerly called outdata), then we give it the compiler generated type of the initialiser, and for debug purposes give it an eponymous type name (eg: _Dobject_ModuleInfoZ symbol has type name struct _Dobject_ModuleInfoZ). This is fine for the workaround so far, but future improvements would be to take the logic from toObjFile / genmoduleinfo and give the fields the correct names when generating the symbol in toSymbol. Alternatively we could store this information within Symbol itself during the toObjFile / genmoduleinfo stage, and have d_finalize_symbol call a routine that will generate the correct type layout to prevent code duplication.On 23 April 2013 17:28, Johannes Pfau <nospam example.com> wrote:Or alternatively we could generate the type (for debugging) on the flying in ::toSymbol 1. Module::toSymbol. Type = Type::moduleinfo type. 2. ClassDeclaration::toSymbol Type = Type::typeinfoclass type. Then for each interface, add the fields for Type::interface onto the type. 3. InterfaceDeclaration::toSymbol Likewise to above.Am Tue, 23 Apr 2013 17:10:43 +0200 schrieb "Iain Buclaw" <ibuclaw ubuntu.com>:Actually, found an interesting problem when confronting it. --- struct Interface { TypeInfo_Class classinfo; void*[] vtbl; ptrdiff_t offset; /// offset to Interface 'this' from Object 'this' <-- } --- I'll have to have a think about what value should be put there, and how best to put it in.In reference to this link: http://forum.dlang.org/post/50476C77.20608 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/62I'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.
May 11 2013