From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-45997-listarch-binutils=sources.redhat.com@sourceware.org>
Received: (qmail 32312 invoked by alias); 19 May 2006 00:37:10 -0000
Received: (qmail 32109 invoked by uid 22791); 19 May 2006 00:37:09 -0000
X-Spam-Check-By: sourceware.org
Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 19 May 2006 00:37:07 +0000
Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) 	by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k4J0aV4S017098; 	Thu, 18 May 2006 17:36:31 -0700 (PDT)
Received: from [17.219.198.72] (unknown [17.219.198.72]) 	(using TLSv1 with cipher RC4-SHA (128/128 bits)) 	(No client certificate requested) 	by relay8.apple.com (Apple SCV relay) with ESMTP id E54B3173; 	Thu, 18 May 2006 17:36:30 -0700 (PDT)
In-Reply-To: <446D11C7.2040008@avtrex.com>
References: <20060518213149.GA14720@nevyn.them.org> <446CEF9F.2070403@avtrex.com> <20060519001101.GA1073@networkno.de> <446D11C7.2040008@avtrex.com>
Mime-Version: 1.0 (Apple Message framework v750)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2C62FB62-DD83-474C-BE86-EBB7D5C55842@apple.com>
Cc: Thiemo Seufer <ths@networkno.de>, Daniel Jacobowitz <drow@false.org>,         binutils@sourceware.org
Content-Transfer-Encoding: 7bit
From: Eric Christopher <echristo@apple.com>
Subject: Re: MIPS textrel fix
Date: Fri, 19 May 2006 10:18:00 -0000
To: David Daney <ddaney@avtrex.com>
X-Mailer: Apple Mail (2.750)
X-IsSubscribed: yes
Mailing-List: contact binutils-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:binutils-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/binutils/>
List-Post: <mailto:binutils@sourceware.org>
List-Help: <mailto:binutils-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: binutils-owner@sourceware.org
X-SW-Source: 2006-05/txt/msg00323.txt.bz2

>
> Not to beat a dead horse, but it would be nice to have a gnu  
> extension that allows us to have read-only eh_frame sections.   
> Large C++ shared libraries have way to many relocations.  It is a  
> lot of dirty pages in the name of ABI compliance.

As long as it doesn't impact handling of other things I'm willing to  
look into it. Need to make sure that we don't base everything on it -  
otherwise we break irix.

-eric