public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Chris Quenelle <chris.quenelle@oracle.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Tristan Gingold <gingold@adacore.com>, binutils@sourceware.org
Subject: Re: Sun/Oracle C++ compiler patch
Date: Fri, 01 Apr 2011 03:13:00 -0000	[thread overview]
Message-ID: <4D9542BB.8080804@oracle.com> (raw)
In-Reply-To: <20110225121917.GK13037@sunsite.ms.mff.cuni.cz>

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.*}) }




  parent reply	other threads:[~2011-04-01  3:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-25  0:17 Chris Quenelle
2011-02-25  9:54 ` Tristan Gingold
2011-02-25 12:19   ` Jakub Jelinek
2011-02-25 18:11     ` Chris Quenelle
2011-04-01  3:13     ` Chris Quenelle [this message]
2011-04-11 15:40       ` Nick Clifton
2011-04-12 21:49         ` Chris Quenelle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D9542BB.8080804@oracle.com \
    --to=chris.quenelle@oracle.com \
    --cc=binutils@sourceware.org \
    --cc=gingold@adacore.com \
    --cc=jakub@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).