-fsection-anchors broken on ARM

[Iain Buclaw]

On 11 May 2013 12:50, Johannes Pfau <nospam at example.com> wrote:

> Am Thu, 09 May 2013 19:40:04 +0200
> schrieb "Iain Buclaw" <ibuclaw at ubuntu.com>:
>
> > On Wednesday, 8 May 2013 at 11:34:19 UTC, Iain Buclaw wrote:
> > > On 24 April 2013 15:12, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
> > >
> > >> On 23 April 2013 18:25, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
> > >>
> > >>> On 23 April 2013 17:28, Johannes Pfau <nospam at example.com>
> > >>> wrote:
> > >>>
> > >>>> Am Tue, 23 Apr 2013 17:10:43 +0200
> > >>>> schrieb "Iain Buclaw" <ibuclaw at 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/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.
> > >>>>
> > >>>>
> > >>> 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.
> > >>>
> > >>>
> > >>
> > >> 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.
> > >>
> > >>
> > > 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.
> > >
> > >
> >
> >
> > 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.
> >
>
> 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.
>

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';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20130511/e70d76ea/attachment.html>