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
