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

[Iain Sandoe <iain at codesourcery dot com>]

Hi Steven,

On 4 Jun 2012, at 13:40, Steven Bosscher wrote:
> 
> asm_out_file for NEXT runtime ABI v01:
> objc/objc-next-runtime-abi-01.c:#include "output.h" /* for asm_out_file */
> objc/objc-next-runtime-abi-01.c:  ASM_DECLARE_UNRESOLVED_REFERENCE
> (asm_out_file, string);
> objc/objc-next-runtime-abi-01.c:  ASM_DECLARE_CLASS_REFERENCE
> (asm_out_file, buf);
> 
> This seems to imply that LTO doesn't work with LTO. The functions that
> use asm_out_file are handle_next_class_ref and handle_next_impent,
> which both only output something for darwin, and are only called via
> called from objc_generate_v1_next_metadata for ABI v1. This code is
> probably not tested very well, because this is for the 32-bits
> ObjC-v2.0 ABI on Darwin, whereas the default 32-bits ABI is ObjC-v1.0
> The code that invokes these functions is this:
> 
>  /* Dump the class references.  This forces the appropriate classes
>     to be linked into the executable image, preserving unix archive
>     semantics.  This can be removed when we move to a more dynamically
>     linked environment.  */
> 
>  for (chain = cls_ref_chain; chain; chain = TREE_CHAIN (chain))
>    {
>      handle_next_class_ref (chain);
>      if (TREE_PURPOSE (chain))
>        generate_classref_translation_entry (chain);
>    }
> 
>  for (impent = imp_list; impent; impent = impent->next)
>    handle_next_impent (impent);

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.

> What is this "more dynamically linked environment" mentioned here? Is
> this an ABI that GCC needs to continue to support?

I don't really know what this comment means either - it predates by time here.. 
.. perhaps Mike could comment?
> 
> (BTW, the GCC manual says: "Starting with GCC 4.7.0, the traditional
> GNU runtime API is no longer available." Shouldn't that be mentioned
> as a caveat in gcc-4.7/changes.html?)

the GNU runtime has it's own handling for these items which differs from NeXT, thus this is an orthogonal issue.

cheers
Iain