From sacadmin Tue Sep 19 15:37:50 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.38]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8JMbo7o000057 for ; Tue, 19 Sep 2006 15:37:50 -0700 (PDT) Received: from [129.146.226.100] (chaz.SFBay.Sun.COM [129.146.226.100]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k8JMbndW206370; Tue, 19 Sep 2006 15:37:50 -0700 (PDT) Message-ID: <4510710A.5090905@sun.com> Date: Tue, 19 Sep 2006 15:36:58 -0700 From: Rod Evans Reply-To: Rod.Evans@sun.com Organization: Sun Microsystems Inc. User-Agent: Mail/News 1.5.0.4 (X11/20060731) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com CC: Ali Bahrami Subject: 2006/549: ld(1) -zrelaxreloc option Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2645 I'm sponsoring the following case for Ali. This case qualifies for Architectural self-review, but we wish to record the following information. ----------------------------------------------------------------------- Add new -z relaxreloc option to ld(1) ----------------------------------------------------------------------- We have received a request to relax the usual rules followed by ld(1) when it handles relocations to discarded COMDAT sections: 6423746 add an option to relax the resolution of COMDAT relocs Normally, a relocation against a discarded section is a fatal error. One might, however, decide to locate the section that was kept, and perform the relocation relative to that kept section. Although one can reasonably assume that all related COMDAT sections are "equivalent", one cannot assume that they are identical, if for no other reason than that they might have been compiled at different optimization levels. Therefore, it is not 100% certain that this is a safe operation. In principle, this sort of sloppy relocation remapping is a questionable practice. All self-referential sections should be in a common SHF_GROUP so that they are all kept or removed together. The problem is that there is no way to ensure that the two sections are similar enough that the replacement section will really supply the correct information. However, we see a couple of situations where it is useful to do this: (1) Older Sun C compilers generated DWARF sections that would refer to one of the COMDAT sections, and (2) gcc, when its COMDAT feature is enabled. It turns out that the GNU ld does these sloppy remappings, and that they are usually related to debug sections and not executable code. It would be best if gcc were modified to generate references to COMDAT sections correctly. Although we believe it will be in time, this is not something that can happen soon. In the meantime, it is important that gcc work well on Solaris. It needs to be possible to use the Solaris ld (and to use important functionality like COMDAT fully). I have therefore implemented the ability for the Solaris linker to handle these sloppy relocations. Although we are able to handle sloppy relocations, the default remains for ld(1) to treat them as fatal link errors. We feel that this is the right policy, and it is not expected to change. The user (usually the gcc wrapper) can request sloppy relocation handling by specifying the new -zrelaxreloc option to ld. ----------------------------------------------------------------------- Release Binding: Patch/Micro z relaxreloc Committed -- Rod.