| |
 | Posted by Mike |  Permalink Reply |
|
Mike 
| http://bugzilla.gdcproject.org/show_bug.cgi?id=99
--- Comment #1 from Mike <slavo5150@yahoo.com> 2014-02-01 11:02:30 GMT ---
Johannes Pfau - 2011-10-05
******************************************
OK, the ClassZ size is bigger as the class implements an interface. This code
interface A {}
class B : A {}
compiled with gdc -c -S test.d produces this
.LC1:
.ascii "test2.B\000"
.data
.align 2
.type _D5test21B7__ClassZ, %object
.size _D5test21B7__ClassZ, 76
_D5test21B7__ClassZ:
.word _D14TypeInfo_Class6__vtblZ
.word 0
.word 12
.word _D5test21B6__initZ
.word 7
.word .LC1
.word 6
.word _D5test21B6__vtblZ
.word 1
.word _D5test21B7__ClassZ+76
.word _D6Object7__ClassZ
.word 0
.word 0
.word 54
.word 0
.word 0
.word 0
.word 0
.word 0
.word _D5test21A11__InterfaceZ
.word 1
.word _D5test21B7__ClassZ+92
.word 8
.word _D5test21B7__ClassZ+76
I'm concerned about this line:
.size _D5test21B7__ClassZ, 76
as size is not 76, even in this simple example it's 96. I'm not sure if the wrong size at this position is a problem, but it seems likely that it causes the issues with anchors: Simply making DefaultTraceInfo a 'normal' class (not implementing an interface) makes the problem go away.
Iain Buclaw - 2011-10-06
******************************************
The issue here is slightly different:
sizeof B == 76
sizeof B.init.type == 96
Johannes Pfau - 2011-11-20
******************************************
Sorry I don't understand your last answer 100%. sizeof B and sizeof B.init.type
are meant to be the same, aren't they? So we'd have to research why those are
different / how to fix that?
Anonymous - 2012-06-12
******************************************
OK, it's been 6 months since I last looked at this, so another try :-)
I diffed the asm output of the core.runtime.d file with sections anchors enabled and with section anchors disabled. I then ported the changes from the no-anchor one to the anchor one, till the anchor one worked. I then removed the changes again, one by one, to find the minimal difference causing the issue.
Turns out, this little asm sequence in function _D4core7runtime9modinitFZv causes the issue:
- movw r3, #:lower16:.LANCHOR1
- movt r3, #:upper16:.LANCHOR1
+ movw r3, #:lower16:__mod_ref.1703
+ movt r3, #:upper16:__mod_ref.1703
ldr r1, [r2, #0]
- str r1, [r3, #76]!
str r3, [r2, #0]
+ str r1, [r3, #0]
This code is correct, but LANCHOR1+76 != __mod_ref.1703 .
LANCHOR1 is defined here:
.LANCHOR1 = . + 0
.type
_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo7__ClassZ,
%object
.size
_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo7__ClassZ,
76
_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo7__ClassZ:
.word _D14TypeInfo_Class6__vtblZ
.word 0
.word 4120
.word
_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo6__initZ
.word 49
.word .LC1
.word 8
.word
_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo6__vtblZ
.word 1
.word
_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo7__ClassZ+76
.word _D6Object7__ClassZ
.word
_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo6__dtorMFZv
.word 0
.word 60
.word 0
.word 0
.word 0
.word
_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo6__ctorMFZC4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo
.word 0
.word _D6object9Throwable9TraceInfo11__InterfaceZ
.word 4
.word
_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo7__ClassZ+92
.word 4116
.word
_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo7__ClassZ+76
.word ___t.0.1647
.word ___t.1.1648
.word ___t.2.1649
.type __mod_ref.1703, %object
.size __mod_ref.1703, 8
__mod_ref.1703:
So the +76 in the anchor code is caused by this line:
.size _D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo7__ClassZ, 76
this is wrong, size of _D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo7ClassZ isn't 76 it's 108.
However, the size classinfo is fixed to CLASSINFO_SIZE and must be 76. Those additional 32 bytes is the interfaces[] array (see toobj.c).
The dmd source (toobj.c, ClassDeclaration::toObjFile(int multiobj)) says
// Put out vtblInterfaces->data[]. Must immediately follow csym, because
// of the fixup (*)
and
// Put out the vtblInterfaces->data[].vtbl[]
// This must be mirrored with ClassDeclaration::baseVtblOffset()
so it seems this is correct and can't be changed in an easy way. We have to make sure GDC doesn't output 76 as the symbols size, but the correct complete size including the interface table. I guess the size is output by the call to toSymbol(); in toobj.c: ClassDeclaration::toObjFile which I guess calls ClassDeclaration::toSymbol() in the end?
Johannes Pfau - 2012-09-06
******************************************
After some more investigation it seems this needs to be fixed in the front end.
I posted a detailed message to the dmd-internals list here:
http://forum.dlang.org/thread/50476C77.20608@googlemail.com
--
Configure bugmail: http://bugzilla.gdcproject.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
|
