From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7218 invoked by alias); 29 Jan 2005 09:58:44 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 7099 invoked from network); 29 Jan 2005 09:58:40 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 29 Jan 2005 09:58:40 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0T9wekj015095 for ; Sat, 29 Jan 2005 04:58:40 -0500 Received: from localhost (mail@vpn50-22.rdu.redhat.com [172.16.50.22]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0T9wdO16171 for ; Sat, 29 Jan 2005 04:58:39 -0500 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1CupNG-0001vj-00 for binutils@sources.redhat.com; Sat, 29 Jan 2005 09:58:38 +0000 To: binutils@sources.redhat.com Subject: Target-specific FDE pointer sizes (3/3) References: <874qh038y1.fsf@redhat.com> <87zmys1szw.fsf@redhat.com> From: Richard Sandiford Date: Sat, 29 Jan 2005 09:58:00 -0000 In-Reply-To: <87zmys1szw.fsf@redhat.com> (Richard Sandiford's message of "Sat, 29 Jan 2005 09:31:31 +0000") Message-ID: <87vf9g1rqp.fsf_-_@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-01/txt/msg00506.txt.bz2 Although the address size problem mentioned in the previous posts: http://sources.redhat.com/ml/binutils/2005-01/msg00504.html http://sources.redhat.com/ml/binutils/2005-01/msg00505.html was a latent bug it only seems to have caused problems after my recent padding optimisation: http://sources.redhat.com/ml/binutils/2005-01/msg00135.html The idea is that we shrink this_inf->size to remove any padding: /* Try to interpret the CFA instructions and find the first padding nop. Shrink this_inf's size so that it doesn't including the padding. */ length = get_DW_EH_PE_width (cie.fde_encoding, ptr_size); insns = skip_non_nops (insns, end, length); if (insns != 0) this_inf->size -= end - insns; and then round it up to the required alignment boundary in size_of_output_cie_fde: return (entry->size + extra_augmentation_string_bytes (entry) + extra_augmentation_data_bytes (entry) + alignment - 1) & -alignment; This should be correct in theory, but it only works if we've got the right value of "alignment" (the number of bytes in a pointer). I wonder if there are other targets for which we underestimate the pointer size, and for which we might therefore end up with misaligned sizes? If this worries anyone, the size shrinking code could be guarded with something like: if (size_of_output_cie_fde (this_inf, ptr_size) > this_inf->size) so that it only triggers when growing the entry. A bit of defensive programming, if you like. My preference would be not to do this. I think it's just another case of "garbage in, garbage out", and I think we could still lose in other ways if we've got the wrong address size. Stiil, I thought I'd better mention it, and I'm certainly happy to make the change if there's demand. Richard