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]
