From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8480 invoked by alias); 5 Aug 2010 14:30:48 -0000 Received: (qmail 8468 invoked by uid 22791); 5 Aug 2010 14:30:47 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Thu, 05 Aug 2010 14:30:42 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 069AE6D42F4; Thu, 5 Aug 2010 16:30:40 +0200 (CEST) Date: Thu, 05 Aug 2010 14:30:00 -0000 From: Corinna Vinschen To: gdb-patches@sourceware.org Subject: Re: [rfa] frame address size incorrect if address size != ptr size Message-ID: <20100805143039.GF4610@calimero.vinschen.de> Reply-To: gdb-patches@sourceware.org Mail-Followup-To: gdb-patches@sourceware.org References: <20100805123043.GD4610@calimero.vinschen.de> <201008051407.o75E7jDO011061@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201008051407.o75E7jDO011061@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-08/txt/msg00033.txt.bz2 On Aug 5 16:07, Ulrich Weigand wrote: > Corinna Vinschen wrote: > > [...] > > If not, I would prefer a solution like this: > > > > - If version > 4, use addr_size from .debug_frame section > > - Otherwise, if we can fetch the target address size from the CU > > header, use it. > > - Otherwise, if the target defined gdbarch_dwarf2_addr_size, use it. > > - Otherwise, default to gdbarch_addr_bit for .debug_frame sections > > and to gdbarch_ptr_bit for .eh_frame sections. > > As I said, finding the .debug_info may be difficult. Also, I'd really > avoid getting another dependency on gdbarch_addr_bit in there; the point > of having a new callback is exactly to avoid overloading addr_bit with > more and more (possibly) different meanings. > > I'd rather just have gdbarch_dwarf2_addr_size default unconditionally > to gdbarch_ptr_bit. In dwarf2-frame we'd then simply use the embedded > addr_size if version >= 4, and gdbarch_dwarf2_addr_size otherwise. > Platforms where ptr_bit is not appropriate simply need to define > gdbarch_dwarf2_addr_size -- since this list is very short, and defining > gdbarch_dwarf2_addr_size correctly is very simple (you just need to look > at the definition of DWARF2_ADDR_SIZE in the corresponding GCC back-end), > that doesn't seem like an unreasonable restriction to me ... > > > > As a side note, it seems odd that add_size is set in those two > > > different locations here. The first one is always overwritten > > > by the second one anyway, isn't it? > > > > There's an early return statement after checking the version number. > > That indicates a failure anyway, so it might be ok to set addr_size > > only once, at the second spot (lines 1779ff). > > Yes, that sounds right to me. Ok, I agree with all you say above. I'm going to create a patch which defines and uses a new gdbarch_dwarf2_addr_size function. It will be defined as a variable like this in gdbarch.sh: v:int:dwarf2_addr_size:::sizeof (void*):0:gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT: Given that, and also given that I will remove the redundant setting of cie->addr_size in decode_frame_entry_1, I have one question left. What about that comment in decode_frame_entry_1? If we only use either the V4 addr_size, or the gdbarch_dwarf2_addr_size function, then the comment really doesn't make much sense anymore in that spot. I'm wondering if it should be moved to the gdbarch.sh file. What do you think? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat