From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14036 invoked by alias); 29 Jan 2008 01:49:28 -0000 Received: (qmail 13984 invoked by uid 22791); 29 Jan 2008 01:49:27 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.179) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 01:49:10 +0000 Received: by py-out-1112.google.com with SMTP id v53so2204766pyh.33 for ; Mon, 28 Jan 2008 17:49:07 -0800 (PST) Received: by 10.35.40.10 with SMTP id s10mr7204483pyj.41.1201571347132; Mon, 28 Jan 2008 17:49:07 -0800 (PST) Received: by 10.35.36.15 with HTTP; Mon, 28 Jan 2008 17:49:07 -0800 (PST) Message-ID: <8f2776cb0801281749w734a3d9h5386a493fb2c2bfb@mail.gmail.com> Date: Tue, 29 Jan 2008 03:42:00 -0000 From: "Jim Blandy" To: "Ulrich Weigand" Subject: Re: [rfc] Make DWARF-2 "address size" explicit Cc: "Jim Blandy" , gdb-patches@sourceware.org In-Reply-To: <200801141554.m0EFskPB011384@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200801141554.m0EFskPB011384@d12av02.megacenter.de.ibm.com> X-Google-Sender-Auth: 00fb923dd2ad651f X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00662.txt.bz2 On Jan 14, 2008 7:54 AM, Ulrich Weigand wrote: > Apart from that, the behaviour should be identical, with one > exception: what address size to use for CFI. Your patch uses > size_of_encoded_value (DW_EH_PE_absptr) > which basically boils down to: > gdbarch_ptr_bit (current_gdbarch) / TARGET_CHAR_BIT > > This would be an effective change in behaviour to what we have > now, which is: > gdbarch_addr_bit (current_gdbarch) / TARGET_CHAR_BIT > > My patch uses in effect > gdbarch_addr_bit (get_frame_arch (frame)) / TARGET_CHAR_BIT > which does not change behaviour. > > However, it might well be that the original code is simply wrong > and we *should* be using ...ptr_bit instead of ...addr_bit. > What do you think? (Sorry --- I thought I had replied to this.) I don't think any change my patch made to the value used there was intentional. Whatever you have determined is the best value to use there is more likely to be right than whatever is in my patch. I don't think this difference is a problem.