From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15230 invoked by alias); 9 May 2011 22:02:58 -0000 Received: (qmail 15200 invoked by uid 22791); 9 May 2011 22:02:56 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate6.uk.ibm.com (HELO mtagate6.uk.ibm.com) (194.196.100.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 May 2011 22:02:41 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate6.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p49M2bwc015264 for ; Mon, 9 May 2011 22:02:37 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p49M2b3I1945740 for ; Mon, 9 May 2011 23:02:37 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p49M2bJw000456 for ; Mon, 9 May 2011 16:02:37 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p49M2anm000447; Mon, 9 May 2011 16:02:36 -0600 Message-Id: <201105092202.p49M2anm000447@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 10 May 2011 00:02:35 +0200 Subject: Re: RFC: implement typed DWARF stack To: tromey@redhat.com (Tom Tromey) Date: Mon, 09 May 2011 22:02:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Tom Tromey" at May 05, 2011 02:14:43 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: 2011-05/txt/msg00234.txt.bz2 Tom Tromey wrote: > Ulrich> [ In fact, maybe we don't need the whole value_cast business and > Ulrich> we could just operate on ULONGEST without involving value_binop, > Ulrich> since both cases only support integers anyway ... ] > > Tom> I agree, for DW_OP_shr. I will do that. Unfortunately I think > Tom> DW_OP_mod still needs special magic. > > Actually in the end I thought it was perhaps better to keep DW_OP_shr > more or less as it was. My reasoning is that by uniformly using the > value API, we make it simpler to handle new cases in the future. E.g., > consider if we want to support 128-bit integer types -- we could do this > via value changes, but this would leave an odd hole in DWARF that the > patch writer would have to discover. OK, fine with me. I guess I still find it a bit odd why we need those DWARF-specific types in the first place (apparently solely for DW_OP_mod), but if we really want to be completely compatible with the prior behaviour, it seems we have to. (Unless DW_OP_mod is defined to always be an unsigned operation, just like DW_OP_shr ...) B.t.w. your patch always performs an unsigned shift for DW_OP_shr, even on signed operands. However, for DW_OP_shra, your patch respects the sign of the operands and might actually perform an unsigned shift (even though the opcode explicitly says "arithmetic right shift" ...) This looks like another of those signed/unsigned inconsistencies with the proposal to me. > Tom> Thanks very much for the review. I'll post a new patch when I've made > Tom> the needed changes. > > Appended. I ran a test on Cell, and interestingly it turns out that while Cell mixed-architecture debugging appears to be OK, just plain ppc32 debugging on a ppc64 host is now broken. When the (32-bit) address of a stack variable has its high bit set, dwarf2_evaluate_loc_desc_full now returns a value with a sign-extended 64-bit CORE_ADDR address (0xffffffff....). This address later on causes a memory_error when accessed. Looking into that, your code does run through value_as_address, but since the platform does not define gdbarch_integer_to_address, this falls through to unpack_long, and since the underlying type is a TYPE_CODE_INT and not a pointer type, this in turn now respects the TYPE_UNSIGNED flag and does a signed conversion ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com