From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30617 invoked by alias); 1 Apr 2011 03:13:16 -0000 Received: (qmail 30608 invoked by uid 22791); 1 Apr 2011 03:13:15 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Received: from rcsinet10.oracle.com (HELO rcsinet10.oracle.com) (148.87.113.121) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 01 Apr 2011 03:13:10 +0000 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p313CoDO023422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2011 03:12:51 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p313CnSC013740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2011 03:12:49 GMT Received: from abhmt005.oracle.com (abhmt005.oracle.com [141.146.116.14]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p313CmFf003801; Thu, 31 Mar 2011 22:12:48 -0500 Received: from dhcp-santaclara18-1fl-west-10-132-141-79.usdhcp.oraclecorp.com (/10.132.141.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 31 Mar 2011 20:12:48 -0700 Message-ID: <4D9542BB.8080804@oracle.com> Date: Fri, 01 Apr 2011 03:13:00 -0000 From: Chris Quenelle User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jakub Jelinek CC: Tristan Gingold , binutils@sourceware.org Subject: Re: Sun/Oracle C++ compiler patch References: <4D66F521.8010902@oracle.com> <50CDB2D0-36A5-48E2-94FE-91F7032F5B0A@adacore.com> <20110225121917.GK13037@sunsite.ms.mff.cuni.cz> In-Reply-To: <20110225121917.GK13037@sunsite.ms.mff.cuni.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-04/txt/msg00002.txt.bz2 On Friday February 25 4:19AM, Jakub Jelinek wrote: > On Fri, Feb 25, 2011 at 10:54:32AM +0100, Tristan Gingold wrote: >> On Feb 25, 2011, at 1:17 AM, Chris Quenelle wrote: >> >>> (ignore the last copy of this email, it had a terrible subject line) >>> >>> Hello, >>> >>> When the Sun/Oracle C++ compiler was ported to Linux, we started >>> bundling a patched version of gnu ld to get the necessary treatment >>> for our exception range sections. I don't believe anyone has tried to >>> offer this patch upstream, and it would really help us out if we could >>> use the system linker when running on Linux. I've included the >>> contents of the patch at the end of this email. >> Just a suggestion: can you add a comment just before to explain that this is for Sun/Oracle C++ compiler ? This is not >> obvious from the section name. >> >> Is the content of this section documented somewhere ? > Also, do you really need ONLY_IF_R{O,W}, i.e. do some older Oracle C++ compiler versions > emit the section writable and some later compilers emit it read-only (or vice versa)? > .eh_frame with very old gcc versions used to be a writable sections that needed > runtime relocation, then gcc changed to a new format which doesn't need any relocations > and thus it is desirable to put the section into a read-only segment if all > .eh_frame input sections are read-only. > > Jakub Sorry for the delay in this thread. I'm not really sure that the "ONLY_IF_RW" in the linker script maps onto the sh_flags field having the SHF_WRITE bit turned on in the section header table. Could you confirm that? Currently our exception range sections are writable, but I haven't been able to confirm that's necessary because of fixups by the C++ runtime system. If it's not necessary or if we change it later, it would be nice if the linker didn't need more modification. Is there any harm in allowing the same behavior if our sections later become read-only? Because of the time-lapse here, I'll include the patch again so that people have context for the thread. --chris % more patch-intel-Linux-2.17.90 *** binutils-2.17.90/ld/scripttempl/elf.sc 2007-08-07 00:00:22.000000000 +0400 --- bu-patched/ld/scripttempl/elf.sc 2008-06-06 15:08:24.602615680 +0400 *************** *** 372,377 **** --- 372,378 ---- .eh_frame_hdr : { *(.eh_frame_hdr) } .eh_frame ${RELOCATING-0} : ONLY_IF_RO { KEEP (*(.eh_frame)) } .gcc_except_table ${RELOCATING-0} : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) } + .exception_ranges ${RELOCATING-0} : ONLY_IF_RO { *(.exception_ranges .exception_ranges*) } /* Adjust the address for the data segment. We want to adjust up to the same address within the page on the next page up. */ *************** *** 382,387 **** --- 383,389 ---- /* Exception handling */ .eh_frame ${RELOCATING-0} : ONLY_IF_RW { KEEP (*(.eh_frame)) } .gcc_except_table ${RELOCATING-0} : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) } + .exception_ranges ${RELOCATING-0} : ONLY_IF_RW { *(.exception_ranges .exception_ranges*) } /* Thread Local Storage sections */ .tdata ${RELOCATING-0} : { *(.tdata${RELOCATING+ .tdata.* .gnu.linkonce.td.*}) }