This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Patch Darwin/Objc] Fix PR 48094.


Hi,

The PR is a(nother) bad interaction between [Darwin/NeXT] ObjC meta-data and LTO.

(for the NeXT runtime) the compiler emits a small block of meta-data "ImageInfo" that conveys to the run-time whether the User had enabled fix-and-continue or objc-gc.  

Since these data are anonymous (the run time finds these data by examining the sections) when we have multiple files, and LTO, we end up with multiple copies of the metadata - which get concatenated.  This is correct behaviour - LTO-wise, but wrong behaviour run-time wise; when presented with multiple objects, the linker normally processes the input copies and produces just one output.  It now complains that that specific meta-data section is too large (we've always been emitting the wrong data, but only picked up on this when the system linker became more picky).  We can't make the section merge-able, or comdat - the first won't work if multiple inputs have differing flags, and the second isn't correct section flags for the runtime.

---

Fortunately, the content of the particular meta-data section only depends on command line switches; Further, these should be the switches in force when the back end runs - and thus should be the switches on the LTO command line.

So the fix proposed does this:

(i)   removes the generation of this meta-data from the ObjC FE.
(ii)  make LTO recognise the relevant c/l switches.
(iii) detect the presence of ObjC/ObjC++ [classes or other metadata] during code-gen.
(iv)  When objc is detected emit the ImageInfo section from the backend.

I did think that there should perhaps be some consideration of keeping the flags and merging them in LTO.  However, I don't think we need to do this with the current code-gen.  There is also evidence that this capability is "going away" in modern Darwin/OSX versions.

In any event, this is an incremental improvement, fixing the cases we see at present;  preserving and checking flags in LTO would be an enhancement that could be provided if it proves necessary.

OK for trunk, and open branches? (wrong code).
Iain

gcc/c-family:

	* c.opt (fgnu-runtime, fnext-runtime, fobjc-abi-version,
	fobjc-gc, freplace-objc-classes): Accept for LTO.

gcc:

	* config/darwin.c (darwin_objc2_section): Note if ObjC Metadata is seen.
	(darwin_objc1_section): Likewise.
	(darwin_file_end): Emit Image Info section when required.

gcc/objc:

	* objc-next-runtime-abi-01.c (generate_objc_image_info): Remove.
	(objc_generate_v1_next_metadata): Remove generation of ImageInfo.
	* objc-next-runtime-abi-02.c (generate_v2_objc_image_info): Remove.
	(objc_generate_v2_next_metadata): Remove generation of ImageInfo.

Attachment: pr48094-diff.txt
Description: Text document



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]