From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13403 invoked by alias); 6 Aug 2010 14:51:12 -0000 Received: (qmail 13342 invoked by uid 22791); 6 Aug 2010 14:51:10 -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 mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.17.163) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Aug 2010 14:51:01 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.1/8.13.1) with ESMTP id o76EovFX017786 for ; Fri, 6 Aug 2010 14:50:57 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 o76Eow2B1798210 for ; Fri, 6 Aug 2010 16:50:58 +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 o76EovjY023153 for ; Fri, 6 Aug 2010 16:50:57 +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 o76EouG2023129 for ; Fri, 6 Aug 2010 16:50:56 +0200 Message-Id: <201008061450.o76EouG2023129@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 06 Aug 2010 16:50:56 +0200 Subject: Re: [rfa] frame address size incorrect if address size != ptr size To: gdb-patches@sourceware.org Date: Fri, 06 Aug 2010 14:51:00 -0000 From: "Ulrich Weigand" In-Reply-To: <20100806104810.GJ4610@calimero.vinschen.de> from "Corinna Vinschen" at Aug 06, 2010 12:48:10 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/msg00066.txt.bz2 Corinna Vinschen wrote: > At one point in this thread you mentioned that .eh_frame isn't really > standarized. > > Additionally, using the pointer size in .eh_frame sections would > invariably break unwinding on targets like avr and XStormy16. No, it would make it work :-) In .eh_frame sections, the contents of DW_EH_PE_absptr encoded fields are *used as pointer values* at run time. See e.g. unwind-pe.h:read_encoded_value_with_base: static const unsigned char * read_encoded_value_with_base (unsigned char encoding, _Unwind_Ptr base, const unsigned char *p, _Unwind_Ptr *val) { union unaligned { void *ptr; unsigned u2 __attribute__ ((mode (HI))); unsigned u4 __attribute__ ((mode (SI))); unsigned u8 __attribute__ ((mode (DI))); signed s2 __attribute__ ((mode (HI))); signed s4 __attribute__ ((mode (SI))); signed s8 __attribute__ ((mode (DI))); } __attribute__((__packed__)); const union unaligned *u = (const union unaligned *) p; _Unwind_Internal_Ptr result; [...] switch (encoding & 0x0f) { case DW_EH_PE_absptr: result = (_Unwind_Internal_Ptr) u->ptr; p += sizeof (void *); break; "p" points directly into the mapped .eh_frame image. The contents are simply interpreted as a native "void *" at run-time. If GDB wants to use this section as well, it has to treat it like it would read a "void *" global variable from the target ... > > It would then be interesting to see whether *both* .debug_frame and > > .eh_frame work on xstormy16 ... you might be able to try the latter > > by building with -fasynchronous-unwind-tables. > > ... .eh_frame sections are never generated for XStormy16. The > -fasynchronous-unwind-tables option is a no-op. OK, that's unfortunate. > Consequentially, is it *really* correct to define the ptr_size as you > requested now, or isn't it *more* correct to use the target dependent > approach as my previous patch implemented? Since it's using the pointer > size as fallback, it will be correct for all existing .eh_frame sections > anyway. 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 ... > * dwarf2-frame.c (struct dwarf2_cie): Add ptr_size member. > Throughout, call read_encoded_value with ptr_size rather than addr_size. > (decode_frame_entry_1): Remove redundant setting of > addr_size. Call gdbarch_dwarf2_addr_size rather than gdbarch_ptr_bit > to determine addr_size in Dwarf versions < 4. Set ptr_size dependent > on examined frame section. Add comment to explain why. > * gdbarch.sh (dwarf2_addr_size): Define as variable. Add lengthy > comment to explain usage. > * gdbarch.c: Regenerate. > * gdbarch.h: Regenerate. > * xstormy16-tdep.c (xstormy16_gdbarch_init): Set dwarf2_addr_size to 4. This looks good to me, except a couple of the comments: > + /* Address values in .eh_frame sections are defined to have the > + target's pointer size. Watchout: This breaks frame info for > + targets with pointer size < address size, unless a .debug_frame > + section exists as well. */ As discussed above, I don't agree that this breaks anything ... Do you still feel it does? > +# dwarf2_addr_size is the target address size as used int the Dwarf debug > +# info. For .eh_frame FDEs this is considered equal to the size of a target > +# pointer. For .debug_frame FDEs, this is supposed to be the target address > +# size from the associated CU header, and which is equivalent to the > +# DWARF2_ADDR_SIZE as defined by the target specific GCC back-end. > +# Unfortunately there is no good way to determine this value. Therefore > +# dwarf2_addr_size simply defaults to the target pointer size. I'd reword this to make clear that this value is *not* used for .eh_frame, but solely for .debug_frame. Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com