From patchwork Wed Aug 27 12:21:06 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulrich Weigand X-Patchwork-Id: 2552 Received: (qmail 31571 invoked by alias); 27 Aug 2014 12:21:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 31557 invoked by uid 89); 27 Aug 2014 12:21:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, MSGID_FROM_MTA_HEADER, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 X-HELO: e06smtp16.uk.ibm.com Received: from e06smtp16.uk.ibm.com (HELO e06smtp16.uk.ibm.com) (195.75.94.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 27 Aug 2014 12:21:14 +0000 Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 27 Aug 2014 13:21:11 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp16.uk.ibm.com (192.168.101.146) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 27 Aug 2014 13:21:08 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 25EBA17D8047 for ; Wed, 27 Aug 2014 13:23:03 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s7RCL8mu21430468 for ; Wed, 27 Aug 2014 12:21:08 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s7RCL7cl028470 for ; Wed, 27 Aug 2014 06:21:07 -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.14.4/NCO v10.0 AVin) with SMTP id s7RCL684028429; Wed, 27 Aug 2014 06:21:06 -0600 Message-Id: <201408271221.s7RCL684028429@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 27 Aug 2014 14:21:06 +0200 Subject: Re: [RFC] Use address_from_register in dwarf2-frame.c:read_addr_from_reg To: pinskia@gmail.com (Andrew Pinski) Date: Wed, 27 Aug 2014 14:21:06 +0200 (CEST) From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org (gdb-patches@sourceware.org) In-Reply-To: from "Andrew Pinski" at Aug 26, 2014 09:01:17 PM MIME-Version: 1.0 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14082712-3548-0000-0000-000001284615 Andrew Pinski wrote: > I think this patch broke MIPS64 n32 big-endian support. We assert here: > gdb_assert (!gdbarch_convert_register_p (gdbarch, regnum, type)); > > The convert_register_p code for MIPS does: > return (register_size (gdbarch, regnum) == 8 > && regnum % num_regs > 0 && regnum % num_regs < 32 > && TYPE_LENGTH (type) < 8); > > > Since the register size is 8 byte wide (MIPS64) and the type length is > 4 (pointer), we return true. In MIPS64, the registers are stored > 64bits but pointers are 32bits. > > Here is the code that is used by mips_register_to_value: > int len = TYPE_LENGTH (type); > CORE_ADDR offset; > > offset = gdbarch_byte_order (gdbarch) == BFD_ENDIAN_BIG ? 8 - len : 0; > if (!get_frame_register_bytes (frame, regnum, offset, len, to, > optimizedp, unavailablep)) > return 0; > > *optimizedp = *unavailablep = 0; > return 1; Huh, I wasn't aware of that conversion. Note that for the register_to_value case, I don't actually see any difference to the default behavior; it's the value_to_register routine that's really special (because of the sign-extension in performs). > Is there a way to fix this in a target neutral way? (I might need a > way like this for AARCH64 ILP32 also). I guess it isn't too hard to support gdbarch_convert_register_p in that routine as well; I just didn't have any target to test on. Can you try whether something along the following lines works for you? Bye, Ulrich ChangeLog: * findvar.c (address_from_register): Handle targets requiring a special conversion routine even for plain pointer types. diff --git a/gdb/findvar.c b/gdb/findvar.c index 41887de..ba3dd4d 100644 --- a/gdb/findvar.c +++ b/gdb/findvar.c @@ -764,11 +764,28 @@ address_from_register (int regnum, struct frame_info *frame) would therefore abort in get_frame_id. However, since we only need a temporary value that is never used as lvalue, we actually do not really need to set its VALUE_FRAME_ID. Therefore, we re-implement - the core of value_from_register, but use the null_frame_id. + the core of value_from_register, but use the null_frame_id. */ - This works only if we do not require a special conversion routine, - which is true for plain pointer types for all current targets. */ - gdb_assert (!gdbarch_convert_register_p (gdbarch, regnum, type)); + /* Some targets require a special conversion routine even for plain + pointer types. Avoid constructing a value object in those cases. */ + if (gdbarch_convert_register_p (gdbarch, regnum, type)) + { + gdb_byte *buf = alloca (TYPE_LENGTH (type)); + int optim, unavail, ok; + + ok = gdbarch_register_to_value (gdbarch, frame, regnum, type, + buf, &optim, &unavail); + if (!ok) + { + /* This function is used while computing a location expression. + Complain about the value being optimized out, rather than + letting value_as_address complain about some random register + the expression depends on not being saved. */ + error_value_optimized_out (); + } + + return unpack_long (type, buf); + } value = gdbarch_value_from_register (gdbarch, type, regnum, null_frame_id); read_frame_register_value (value, frame);