[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-05 21:01:09 UTC ---
(In reply to comment #11)

> I think that later versions of the vendor's tools make some of the ObjC
> sections merge-able - so that's a possibility 

Unfortunately, not the _image_info sections.

===

So .. this is the problem....

We have n object files input to lto.  Each object contains ObjC meta-data...
including a single var in the _image_info section.

Although these image_info  vars will eventually be overlaid, they are not
common-like - because they can be non-zero.

(Darwin's) ld can merge them, because ld knows that the property of the
_image_info section is that it holds a single instance of the L_OBJC_ImageInfo
variable.

So ld can check that these are compatible between objects, and merge/error as
appropriate.

but LTO will concatenate them - leading to two problems:
 (a) the section appears to be too big - complaint from later versions of ld
and 
 (b) they are no longer being error-checked and combined - which might have
much more subtle implications.

> - otherwise - Honza any suggestions?

e.g.
Is there any annotation or hook that we can use to emulate this behavior?

(I don't think DECL_ONE_ONLY is quite right because it might be [legitimately]
possible for the vars to have differing values - I need to check that
carefully)

I guess, ideally, the ObjC meta-data should be re-created after LTO has done
its magic -- but that's def. not a stage 3 type job ...

.. maybe move it to be a late (Post Optimization) pass? 

[ISTM, at a first consideration, there should be no need to optimize ObjC
metadata under those circumstances, since it should only be created as required
in response to the remaining (optimized) content]