Bug 48109 - Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1
Summary: Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: objc (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Iain Sandoe
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-14 09:36 UTC by Iain Sandoe
Modified: 2013-09-01 20:11 UTC (History)
3 users (show)

See Also:
Host: *-apple-darwin*
Target: *-apple-darwin*
Build: *-apple-darwin*
Known to work:
Known to fail:
Last reconfirmed: 2011-03-14 10:29:40


Attachments
possible fix - shifting the special case output of objc_class_name_xxxx to the back-end. (2.22 KB, patch)
2011-03-14 18:20 UTC, Iain Sandoe
Details | Diff
possible fix v2 - shifting the special case output of objc_class_name_xxxx to the back-end. (2.38 KB, patch)
2011-03-14 20:51 UTC, Iain Sandoe
Details | Diff
updated to trunk @175628. (2.50 KB, patch)
2011-06-29 20:08 UTC, Iain Sandoe
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Iain Sandoe 2011-03-14 09:36:58 UTC
This is a FE bug that manifests only on Darwin/NeXT (m32) under LTO.

(originally reported as part of PR48094)

e.g.

-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libobjc/.libs
  -lobjc     -m32 -o objc-dg-lto-trivial-1-21    (timeout = 300)
ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in
/var/tmp//ccMlEsXS.lto.o^M
Undefined symbols for architecture i386:^M
  ".objc_class_name_myRootObject", referenced from:^M
      pointer-to-literal-objc-class-name in ccMlEsXS.lto.o^M
      pointer-to-literal-objc-class-name in ccMlEsXS.lto.o^M
ld: symbol(s) not found for architecture i386^M

---

The reason is an anachronism in using target macros to emit efficient representations of class presence and requirement (ASM_DECLARE_CLASS_REFERENCE/ASM_DECLARE_UNRESOLVED_REFERENCE).

.. because of this, there are no real vars representing the presence/requirement for the classes and, when LTO is engaged, the information is lost.

The separate external defs/refs are required because the class metadata structures are all local to a given TU.  The refs meet the linkage requirements.

For the m64 ABI-2 this is not longer an issue, since class metadata definitions are now external and thus visible without additional action.
Comment 1 Mike Stump 2011-03-14 10:23:19 UTC
Not sure it matters, but, marking them as used should be enough...  Note, there are a couple of ways to mark things.  TREE_USED and the lto incantation.
Comment 2 Iain Sandoe 2011-03-14 10:29:40 UTC
(In reply to comment #1)
> Not sure it matters, but, marking them as used should be enough...  Note, there
> are a couple of ways to mark things.  TREE_USED and the lto incantation.

they never exist to be marked:


handle_next_class_ref (tree chain)
{
  const char *name = IDENTIFIER_POINTER (TREE_VALUE (chain));
  char *string = (char *) alloca (strlen (name) + 30);

  sprintf (string, ".objc_class_name_%s", name);

#ifdef ASM_DECLARE_UNRESOLVED_REFERENCE
  ASM_DECLARE_UNRESOLVED_REFERENCE (asm_out_file, string);

>>>>  this just emits .lazy_reference .objc_class_name_xxxxx

#else
  return ; /* NULL build for targets other than Darwin.  */
#endif
}
Comment 3 Richard Biener 2011-03-14 11:27:31 UTC
I suppose a special kind of alias could be invented here.
Comment 4 Iain Sandoe 2011-03-14 11:36:29 UTC
(In reply to comment #3)
> I suppose a special kind of alias could be invented here.

I was thinking of a normal var - tagged with our ObjC meta-data attribute - and then handled in the back end.

- this is supposing that varasm.c would be a valid place to recognize ASM_DECLARE_CLASS_REFERENCE/ASM_DECLARE_UNRESOLVED_REFERENCE (or a suitable hook to replace them)

- alternatively, the var could be zero-sized, which (together with the ObjC meta-data attribute) can be picked up in darwin.c (but that's maybe kinda hacky).
Comment 5 Iain Sandoe 2011-03-14 18:20:15 UTC
Created attachment 23653 [details]
possible fix - shifting the special case output of objc_class_name_xxxx to the back-end.

this solves the problem of propagating the class refs/defs through LTO
... although it reveals that we have further issues when -flto-partition=none is used 
   (duplicate meta-data definitions - however, this latter problem is not specific to darwin and will be posted as a different PR)

... only lightly tested on i686-darwin9.

opinions?
Comment 6 Iain Sandoe 2011-03-14 18:31:13 UTC
BTW, if we go this route (or almost any I can think of) we could have a separate patch to remove 
ASM_DECLARE_CLASS_REFERENCE/ASM_DECLARE_UNRESOLVED_REFERENCE which are only used for this one purpose AFAICT.
Comment 7 Iain Sandoe 2011-03-14 20:51:24 UTC
Created attachment 23655 [details]
possible fix v2 - shifting the special case output of objc_class_name_xxxx to the back-end.

improved version (more logical in that it actually makes the reference into a real reference in the absence of the hook).

built on i686-linux as well as i686-darwin9 ... seems to produce the expected output on both.
Comment 8 Mike Stump 2011-03-14 23:39:21 UTC
Seems reasonable to me...
Comment 9 Iain Sandoe 2011-06-29 20:08:33 UTC
Created attachment 24641 [details]
updated to trunk @175628.

this patch posted to GCC-patches:

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02268.html
Comment 10 Iain Sandoe 2012-07-09 08:43:33 UTC
this is now fixed on trunk by:
http://gcc.gnu.org/viewcvs?view=revision&revision=188793

We will have to consider whether it is a reasonable back-port (at least to 4.7). Although it touches objc and doc, it is localized in effect to Darwin.
Comment 11 Iain Sandoe 2013-09-01 20:11:13 UTC
back-ported to 4.7 (sorry it took so long) as 202155, thus fixed.