From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11901 invoked by alias); 9 Sep 2009 23:44:05 -0000 Received: (qmail 11875 invoked by uid 22791); 9 Sep 2009 23:44:04 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Sep 2009 23:43:58 +0000 Received: (qmail 5255 invoked from network); 9 Sep 2009 23:43:56 -0000 Received: from unknown (HELO ?192.168.5.188?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Sep 2009 23:43:56 -0000 Message-ID: <4AA83DB7.8060102@codesourcery.com> Date: Wed, 09 Sep 2009 23:44:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mark Mitchell , binutils@sources.redhat.com, rdsandiford@googlemail.com Subject: Re: Should MIPS .eh_frame be writable? References: <4AA66F4D.2040001@codesourcery.com> <87bpll1dc5.fsf@firetop.home> <4AA6A975.5090309@codesourcery.com> <8763bt1aix.fsf@firetop.home> <4AA6BD82.9020802@codesourcery.com> <87iqfrbz0j.fsf@firetop.home> In-Reply-To: <87iqfrbz0j.fsf@firetop.home> Content-Type: text/plain; charset=ISO-8859-1 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: 2009-09/txt/msg00273.txt.bz2 Richard Sandiford wrote: > But I see that more as an argument about whether something like > --warn-shared-textrel should be the default (or even a hard error > by default). Just as the assembler doesn't know whether the section will end up read-only, the linker doesn't know what the target is. :-) In particular, on MIPS GNU/Linux, the linker doesn't know whether it's building an application for use with uClibc or GLIBC. So, warning might make sense, but issuing an error wouldn't. > (I'm still approaching this from the angle that it's the assembly > writer's responsibility to make sure that their .cfi_* directives > are suitable for a read-only .eh_frame.) That's where I see it differently. I think that the tools shouldn't allow me to lie, at least when they can detect I'm lying. If I have relocations against my read-only section, the tools can know that, and I'm clearly confused. I deserve slappage. >> I'd suggest having GAS mark the sections read-write, and having the >> linker treat them as read-only if it can eliminate the relocations. > > So GAS would make the section read-write if detects a relocation, > and the linker would make it read-only again if it detects that > all relocations have been removed? Yes. I think that's the most conservative approach. As a further extension, allow a directive that says "this section is supposed to be read-only" and have the tools complain if that assumption is violated; GCC, in particular, could emit the directive with .eh_frame. In other words, have the tools be mutually suspicious, rather than blindly trusting. > Will do. Looks like a small linker change might be needed too, > so we should probably make GCC default to -fno-dwarf2-cfi if we > a linker that doesn't have it. As far as gcc branches go, > we should probably make -fno-dwarf2-cfi the default for MIPS, > since this is a regression. OK. For avoidance of doubt :-), the change I proposed (namely, telling GAS to mark .eh_frame read-write) is not *wrong* (and in fact consistent with past practice), but is *suboptimal* (in that you can tweak things to make .eh_frame read-only, and, of course, it's generally better to have more of your program be read-only). Right? (That's a question dressed up as an assertion.) Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713