Re: [RFH] Uses of output.h in the front ends

[Iain Sandoe <iain at codesourcery dot com>]

Hi Steven,

On 5 Jun 2012, at 19:01, Steven Bosscher wrote:

> On Tue, Jun 5, 2012 at 4:15 PM, Iain Sandoe <iain@codesourcery.com> wrote:
>> As it happens, the code should be as well-tested as for V1 as V2 ABI -
>> since it is conventional to test ObjC/NeXT at m32(V1) and m64(V2) [[and
>> also the GNU runtime (on Darwin)]].
>> 
>> So whilst Darwin is not as well-tested as linux, at least the coverage
>> is the same on all supported ObjC variants.
>> 
>> You are right, it is broken for LTO.
>> 
>> PR 48109 applies.
>> 
>> I have two ideas at present for how to remove these two uses in ObjC FE:
>> 
>> (1)  Turn these 'ghost' items into real variables and use the existing
>> mechanism [meta-data attributes] to tag the items as needing special
>> handling by the back-end.   This is done for other ObjC meta-data, since
>> they need to be placed in the correct sections for the runtime to find them.
>> 
>> I posted a patch to implement this (allowing a target to intercept
>> assemble-variable at a high level)
>> 
>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02268.html
>> 
>> there were changes requested by reviewers that I haven't been able to
>> find time to address just yet, but it might still be an appropriate
>> way forward.
>> 
>> (2) Since this is Darwin/NeXT-specific, make the back-end recognise the
>> need to synthesise these two particular meta-data.  This is not quite
>> so easy, but I haven't spent a lot of time on it yet.
> 
> Or: Since this is Darwin/NeXT-specific, hack around it by emitting
> these things as top-level asms. That would make things with with LTO
> also, and it is probably the easiest solution. It is a bit of a hack,
> but IMHO that's not a problem for something as target-specific as
> this.
> 
> If I can turn that idea into a patch, can you test it for me?

certainly,

I would welcome a simple solution if one is available, although I don't quite see what you have in mind at present.

A recap on the background might be in order.

The (NeXT v1) ObjC meta-data for classes are stored in specific named sections with a layout known to the runtime.  Because of this, class definitions do not need (or have) any externally-visible symbols;  the runtime finds what it wants by processing the named sections directly. 

This is fine until we need to decide on which modules should be linked into an exe from objects containing ObjC classes.

To resolve this two entities are created, a class ref and a class def - which produce only symbol table content.

This 'zero-space' def/ref system, with symbols in a specific form, must be adhered to [Darwin's] ld expects it and processes these special symbols accordingly.

[JFTR, NeXT v2/m64 does not have this issue, the class defs are public symbols, so it all 'just works']

cheers
Iain

> PS: nice to see you have a new employer ;-)

Thanks! ... an exciting time for me.