From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32668 invoked by alias); 31 Oct 2007 01:51:35 -0000 Received: (qmail 32659 invoked by uid 22791); 31 Oct 2007 01:51:34 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 31 Oct 2007 01:51:32 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9V1pTvO412350 for ; Wed, 31 Oct 2007 01:51:29 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.5) with ESMTP id l9V1pTkT2113628 for ; Wed, 31 Oct 2007 02:51:29 +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 l9V1pT04008150 for ; Wed, 31 Oct 2007 02:51:29 +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 l9V1pTLb008147; Wed, 31 Oct 2007 02:51:29 +0100 Message-Id: <200710310151.l9V1pTLb008147@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 31 Oct 2007 02:51:29 +0100 Subject: dwarf2-frame.c read_reg problems, again ... To: drow@false.org Date: Wed, 31 Oct 2007 02:18:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org 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: 2007-10/txt/msg00840.txt.bz2 Dan, the patch you committed to read_reg last year: http://sourceware.org/ml/gdb-patches/2006-05/msg00089.html in combination with the recent switch to XML register definitions, appears to cause problems in ppc64 x ppc32 bi-arch debugging. Specifically, when debugging a 32-bit inferior on a 64-bit system, the DWARF-2 unwinder now sign-extends the CFA values to 64-bit (as the stack addresses are typically in the 0xf0000000 range, this is an actual problem). As long as every CFA is treated the same, this is does not really matter. However, if there are "special" frames (signal trampoline or dummy frames) in between, *their* unwinders do *not* sign-extend the CFA. This causes the generic frame code to stop unwinding with "previous frame inner to this frame" errors. With the patch refered to above, read_reg will respect the signedness of the register_type, if it is an integral type. This is not a problem if the register type is a pointer type (in which case pointer_to_address would be consulted), but on ppc the CFA gets computed from regular general purpose registers, with an integral register_type. Those in turn used to be described as "builtin_type_uint32" by the original rs6000_register_type. The generic XML-based machinery now apparently uses a signed integer type instead, exposing the problem. Now I'm wondering: what was the motivation behind using unpack_long here? The dwarf2loc.c:dwarf_expr_read_reg routine, which saves basically the same purpose, now uses address_from_register -- i.e. specifically treats the value as pointer, not integer ... I guess we could change the XML definitions to force the general purpose registers back to unsigned types, but that doesn't seem a real solution to me. Any suggestions how to fix this? Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com