From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28119 invoked by alias); 28 Jan 2008 20:53:03 -0000 Received: (qmail 28108 invoked by uid 22791); 28 Jan 2008 20:53:02 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.29.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 28 Jan 2008 20:52:36 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id m0SKqXw6018672 for ; Mon, 28 Jan 2008 20:52:33 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 v8.7) with ESMTP id m0SKqW9W1323200 for ; Mon, 28 Jan 2008 21:52:32 +0100 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 m0SKqWZ7030062 for ; Mon, 28 Jan 2008 21:52:32 +0100 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 m0SKqW4K030059; Mon, 28 Jan 2008 21:52:32 +0100 Message-Id: <200801282052.m0SKqW4K030059@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 28 Jan 2008 21:52:32 +0100 Subject: Re: [rfc] Make DWARF-2 "address size" explicit To: jimb@codesourcery.com, drow@false.org Date: Mon, 28 Jan 2008 21:08:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <200801141554.m0EFskPB011384@d12av02.megacenter.de.ibm.com> from "Ulrich Weigand" at Jan 14, 2008 04:54:46 PM X-Mailer: ELM [version 2.5 PL2] 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: 2008-01/txt/msg00655.txt.bz2 I 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? The notion of "target address size" is relevant in several places of Dwarf Call Frame Information: target addresses are used explicitly in the "initial location" and "address range" fields of the FDE header, as well as as immediate operand of the DW_CFA_set_loc call frame instruction. In addition, the DW_CFA_def_cfa_expression, DW_CFA_expression and DW_CFA_val_expression call frame instructions refer to DWARF expressions as operand, which implicitly depend on the target address size: first, the whole process of expression evaluation implicitly depends on the target address size in that each element of the stack used is considered to be of target address size (this affects e.g. rounding/truncation of arithmetic operations). In addition, the DW_OP_addr operation explicitly takes an immediate target address as operand, and the DW_OP_deref and DW_OP_xderef operations implicitly use the target address size. I've now looked both at generation of CFI by GCC (dwarf2out.c) and use of CFI by the GCC exception handling runtime (unwind-dw.c) to try to determine what GCC uses and/or expects as "target address size" in all of those cases. Note that the CFI provided in the (standard) .debug_frame section and the CFI in the (GCC / C++ ABI extension) .eh_frame section *differ* in critical aspects here. For the explicit uses of target addresses in FDE header fields and the DW_CFA_set_loc instruction the situation is pretty clear. For .debug_frame, GCC uses its notion of "DWARF2_ADDR_SIZE" to define the target address size. This is a value that defaults to the size of a "void *" on the target, but can be overridden by the platform back-end. This currently appears to be done by xstormy16, m68hc11, m32c, and avr (which use a 4-byte DWARF address size even while using 2-byte pointers), as well as certain ABI modes of mips64 (where the DWARF address size is defined by -mabi= while the pointer size is defined by -mlong32 vs. -mlong64). Note that this value is used throughout the .debug_ sections, and could be retrieved e.g. from the .debug_info address size header field. For .eh_frame, GCC uses a completely different way to represent target addresses: the "FDE encoding" field of the CIE augmentation record defined which of a variety of encoding methods is used to encode the FDE header fields as well as the DW_CFA_set_loc operand. Most of these encodings explicitly specify a size; those that rely on an implicit address size (DW_EH_PE_aligned, DW_EH_PE_absptr and DW_EH_PE_indirect) always employ the size of a "void *" (*not* the "DWARF2 address size as used in .debug_frame!). As should be expected, the GCC code generator and the GCC exception runtime are in complete agreement on this. (This applies to .eh_frame only, there is no *user* of .debug_frame anywhere in GCC.) For the address sizes used in DWARF *expressions*, the picture gets a lot less clear. (Un?)fortunately, GCC currently generates only a small subset of DWARF expressions as part of call frame information. It never generates DW_CFA_expression or DW_CFA_val_expression, and while it does generate DW_CFA_def_cfa_expression instructions, they only contain a subset of all possible expressions. In particular, they never contain DW_OP_addr; GCC simply assumes arithmetic operations never wrap so the exact size used for the value stack does not matter; and DW_OP_deref is only generated for some platforms (where apparently the address size issue doesn't really come up). On the other hand, in some places GCC seems to assume an address size as specified by DWARF2_ADDR_SIZE (both for .eh_frame and .dwarf_frame -- this certainly appears to be broken ...). On the user side, the exception handling infrastructure assumes the size of "void *" for DW_OP_addr and DW_OP_deref, but uses "_Unwind_Word" (which represents the size of a target *register*, not necessarily a target pointer) as size of the value stack elements. (Again this applies to .eh_frame only, there is no user of .debug_frame in GCC.) When comparing all this with what GDB currently does, there is one obvious error: GDB does not take the FDE encoding into account *at all* when accessing the operand of DW_CFA_set_loc in the .eh_frame section. It looks like this was already noticed by Dan some time ago, but the associated patch: http://www.cygwin.com/ml/gdb-patches/2006-10/msg00063.html apparently was never applied. Dan, are you still planning on applying this patch? Apart from that, it would appear that the most logical size to use for target addresses in DWARF expression evaluation would be the target "void *" size for .eh_frame FDEs, and the value of the associated compilation unit's .debug_info address size header field value for .debug_frame FDEs (however, I'm not sure how to best determine that). Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com