From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30606 invoked by alias); 6 Aug 2010 16:27:44 -0000 Received: (qmail 30594 invoked by uid 22791); 6 Aug 2010 16:27:43 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.17.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Aug 2010 16:27:37 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id o76GRW6O008385 for ; Fri, 6 Aug 2010 16:27:32 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o76GRW1V1708088 for ; Fri, 6 Aug 2010 18:27:32 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o76GRWTY002297 for ; Fri, 6 Aug 2010 18:27:32 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o76GRVra002284 for ; Fri, 6 Aug 2010 18:27:31 +0200 Message-Id: <201008061627.o76GRVra002284@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 06 Aug 2010 18:27:31 +0200 Subject: Re: [rfa] frame address size incorrect if address size != ptr size To: gdb-patches@sourceware.org Date: Fri, 06 Aug 2010 16:27:00 -0000 From: "Ulrich Weigand" In-Reply-To: <20100806155738.GA2815@calimero.vinschen.de> from "Corinna Vinschen" at Aug 06, 2010 05:57:38 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00073.txt.bz2 Corinna Vinschen wrote: > On Aug 6 16:50, Ulrich Weigand wrote: > > The difference between .eh_frame and .debug_frame is really fundamental; > > .eh_frame holds *pointer* values in target "void *" format; while > > .debug_frame holds *address* values using the same format as the rest > > of the DWARF debug sections. > > > > Therefore we will definitely have to make a distinction between the two. > > If you have another suggestion how to achieve that, I'd certainly be > > interested ... > > I understand what you're up to, but to me this means that the above code > from unwind-pe.h is potentially not usable for certain small targets, > unless some conditions are met. > > As it is the one example I really know well, let's stick to XStormy16 > for now. > > The problem for XStormy16 in 16 bit pointer mode is that a pointer is > not able to point to every place in the 24 bit address space the CPU can > address. For function pointers that means that the target potentially > has to use a jump table. For the stack that means it is restricted to > the first 64K RAM. > > So, afaics, the unwind-pe.h code only works correct for XStormy16, if > either the application fits into the first 64K of memory, or if > DW_EH_PE_absptr is not used, rather DW_EH_PE_pcrel, DW_EH_PE_textrel, > DW_EH_PE_datarel, or DW_EH_PE_funcrel. Oh, and then there's the > type of _Unwind_Ptr, which would have to be big enough, 32 bit. OK, I see what you mean. So if we were to enable DWARF EH for XStormy16, we'd either have to do what you just described (all of which should in principle be doable), or else add something new to support larger "pointer" or address types. I'd assume this might then be a new encoding type ... In any case, I'd still say that GDB today ought to match what GCC today does, which is that DW_EH_PE_absptr encoding uses target-format pointers. If and when GCC is extended, say to support another encoding type, we'd then likewise extend GDB to support that new feature. > > I'd reword this to make clear that this value is *not* used for .eh_frame, > > but solely for .debug_frame. > > Ok, will do. I'd just like to put the discussion to an end, first. > Just tell me what you think of what I wrote above. Does the above make sense to you? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com