From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12902 invoked by alias); 8 Sep 2009 19:50:31 -0000 Received: (qmail 12892 invoked by uid 22791); 8 Sep 2009 19:50:29 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from an-out-0708.google.com (HELO an-out-0708.google.com) (209.85.132.249) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Sep 2009 19:50:21 +0000 Received: by an-out-0708.google.com with SMTP id c5so1372376anc.35 for ; Tue, 08 Sep 2009 12:50:18 -0700 (PDT) Received: by 10.101.57.4 with SMTP id j4mr17183483ank.104.1252439418914; Tue, 08 Sep 2009 12:50:18 -0700 (PDT) Received: from localhost (79-67-69-193.dynamic.dsl.as9105.com [79.67.69.193]) by mx.google.com with ESMTPS id 38sm606924agd.76.2009.09.08.12.50.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Sep 2009 12:50:17 -0700 (PDT) To: Mark Mitchell Mail-Followup-To: Mark Mitchell ,binutils@sources.redhat.com, rdsandiford@googlemail.com Cc: binutils@sources.redhat.com Subject: Re: Should MIPS .eh_frame be writable? References: <4AA66F4D.2040001@codesourcery.com> <87bpll1dc5.fsf@firetop.home> <4AA6A975.5090309@codesourcery.com> From: Richard Sandiford Date: Tue, 08 Sep 2009 19:50:00 -0000 In-Reply-To: <4AA6A975.5090309@codesourcery.com> (Mark Mitchell's message of "Tue\, 08 Sep 2009 14\:59\:01 -0400") Message-ID: <8763bt1aix.fsf@firetop.home> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00238.txt.bz2 Mark Mitchell writes: > Richard Sandiford wrote: >> The relocations are only for the personality routines, right? > > Yes. > >> If so, then I think we should simply use an indirect encoding. >> I'll do a (gcc) patch. > > That's clearly ideal; I wasn't sure if it was possible. But, it doesn't > solve the problem that there are versions of GCC out there generating > code that results in a read-write frame. Well, this problem only occurs for GCCs that use .cfi_* directives, and you can always use -fno-dwarf2-cfi-asm as a workaround if you're not able to upgrade or patch your GCC. > I think it's bad if GAS marks a section as read-only when it should > know that it's not. Shouldn't GAS check that it's really generating a > read-only frame before setting the read-only bit? GAS doesn't know for sure, because the linker can turn absolute relocations into PC-relative ones. That's how we get rid of all the object-local relocations on MIPS, even though the original code uses absolute addresses. Or stepping back a bit, the problem is that you have traditionally not been able to do: .4byte x-. on MIPS, for some extern variable "x". The same thing is true if "x" is in another section of the same assembly file. So MIPS used absolute relocations for all .eh_frame references. This meant that MIPS objects couldn't have an .eh_frame_hdr, because we didn't know the code regions at link time. This in turn tickled a bug in glibc that the maintainer didn't think should be fixed (namely, its .eh_frame wasn't null-terminated). So the dilemma I had was: should we add the "x-." feature as a GNU extension, or should we stick to the traditional ABI and fix it up in the linker? We already did a fair amount of linker optimisation at the time, and turning absolute addresses into PC-relative values -- and changing the encoding accordingly -- seemed like a useful optimisation. Plus it had the advantage that it would work with old object files. So that's what I ended up doing. However, GCC still marked its own .eh_frames as writable, so it never really mattered that the personality routines still needed relocations. On the other hand, MIPS GAS has always marked .cfi_*-based sections as read-only, and I think it would be a mistake to change that. Assembly-language programmers are probably getting this right, and as I say, GAS doesn't know for sure whether they are or not. In summary, I think this is genuinely a GCC bug. When using .cfi_* directives, it should take account of the fact that GAS will mark the .eh_frame section read-only. Richard