From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11291 invoked by alias); 27 Aug 2014 18:15:20 -0000 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 Received: (qmail 11251 invoked by uid 89); 27 Aug 2014 18:15:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Aug 2014 18:15:12 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1XMhkS-0000Ny-Pf from Maciej_Rozycki@mentor.com ; Wed, 27 Aug 2014 11:15:08 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Aug 2014 11:15:08 -0700 Received: from localhost (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 27 Aug 2014 19:15:06 +0100 Date: Wed, 27 Aug 2014 18:15:00 -0000 From: "Maciej W. Rozycki" To: Ulrich Weigand CC: Andrew Pinski , "gdb-patches@sourceware.org" Subject: Re: [RFC] Use address_from_register in dwarf2-frame.c:read_addr_from_reg In-Reply-To: <201408271221.s7RCL684028429@d06av02.portsmouth.uk.ibm.com> Message-ID: References: <201408271221.s7RCL684028429@d06av02.portsmouth.uk.ibm.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-08/txt/msg00586.txt.bz2 On Wed, 27 Aug 2014, Ulrich Weigand wrote: > 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? I'll see if I can push it through testing, though it may take a few days as some of MIPS hardware I use (and especially 64-bit one) is slooow (and I already have a test run under way). I'd expect the issue to be consistent across all ILP32 64-bit ABIs BTW, that is e.g. x32 x86-64 as well. Maciej