[Bug 99] -fsection-anchors broken on ARM

[gdc-bugzilla at gdcproject.org]

http://bugzilla.gdcproject.org/show_bug.cgi?id=99

--- Comment #1 from Mike <slavo5150 at 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.