From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107589 invoked by alias); 13 Apr 2016 21:57:34 -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 107571 invoked by uid 89); 13 Apr 2016 21:57:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=master's, Hx-languages-length:3351, bingo, era X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 13 Apr 2016 21:57:23 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0E4EE85A00; Wed, 13 Apr 2016 21:57:22 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3DLvKRZ010369; Wed, 13 Apr 2016 17:57:20 -0400 Subject: Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message To: Orgad Shaneh References: <570C14D4.3030600@codesourcery.com> <570CFA04.3070109@codesourcery.com> <570E99DC.8080902@codesourcery.com> <570EABAA.50908@redhat.com> Cc: Luis Machado , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <570EC0C0.8030500@redhat.com> Date: Wed, 13 Apr 2016 21:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00310.txt.bz2 On 04/13/2016 09:52 PM, Orgad Shaneh wrote: > On Wed, Apr 13, 2016 at 11:27 PM, Pedro Alves wrote: >> So there's no xml target description involved? It sounds like >> either the default layout or some of the mips_register_g_packet_guesses >> guesses is taking effect then. >> >> If the size of the register file gdbserver is sending is larger than >> what gdb is expecting, then it's possible to register offsets >> are mismatched as well. >> >> Figure out what set of registers gdbserver is sending, and compare to >> "maint print remote-registers", after connecting. What's the mismatch? > > See the attached files. > > gdb-local-6.5 is a local execution of gdb on the target machine. > gdb-remote-7.4 is the output of 7.4 official version (without Cavium > patches), which works. > gdb-remote-7.6 is the output of 7.6 Cavium version, which doesn't. > Bah, mips uses masking pseudo registers for all registers, so "maint print remote-registers" doesn't show the registers' names. However, we can see that gdb 7.4 expects more registers, as expected, and that it expects registers up till register 89: ... '' 88 88 704 8 int64_t 88 704 '' 89 89 712 8 int64_t 89 712 ... while 7.6 expects registers up till register number 78: ... '' 77 77 616 8 int64_t 77 616 '' 78 78 624 8 int64_t 78 624 ... I'd compare "info all-registers" to paint a more complete picture. Looking at current master's mips-tdep.c, we see: static struct gdbarch * mips_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) { ... else if (info.osabi == GDB_OSABI_LINUX) { ... num_regs = 79; ... } else { num_regs = MIPS_LAST_EMBED_REGNUM + 1; ... } ... And in mips-tdep.h, we see: ... MIPS_LAST_EMBED_REGNUM = 89 /* Last one. */ ... So, bingo, it seems? Old gdbserver is sending the embedded layout, while newer gdb expects the linux-specific layout. In current master we have: static void mips_register_g_packet_guesses (struct gdbarch *gdbarch) { /* If the size matches the set of 32-bit or 64-bit integer registers, assume that's what we've got. */ register_remote_g_packet_guess (gdbarch, 38 * 4, mips_tdesc_gp32); register_remote_g_packet_guess (gdbarch, 38 * 8, mips_tdesc_gp64); /* If the size matches the full set of registers GDB traditionally knows about, including floating point, for either 32-bit or 64-bit, assume that's what we've got. */ register_remote_g_packet_guess (gdbarch, 90 * 4, mips_tdesc_gp32); register_remote_g_packet_guess (gdbarch, 90 * 8, mips_tdesc_gp64); /* Otherwise we don't have a useful guess. */ } Specifically, the: register_remote_g_packet_guess (gdbarch, 90 * 8, mips_tdesc_gp64); line should match this. So seems like this _should_ be working. git blame points at around the initial mips linux gdbserver submission: https://sourceware.org/ml/gdb-patches/2006-11/msg00057.html That's 6.6 era, not 7.6.. So it may be this guessing mechanism is broken. If so, that's where the fixing should be aimed at. If not, well, we should figure out more. > gdb-remote-7.6 is the output of 7.6 Cavium version, which doesn't. TBC, does this happen with current FSF master against old (unpatched) FSF 7.4 gdbserver? This might be due to local Cavium patches... Thanks, Pedro Alves