From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49727 invoked by alias); 14 Apr 2016 21:21:13 -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 49715 invoked by uid 89); 14 Apr 2016 21:21:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=picture X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Apr 2016 21:21:02 +0000 Received: from hhmail02.hh.imgtec.org (unknown [10.100.10.20]) by Websense Email with ESMTPS id D59887DB8ED7F; Thu, 14 Apr 2016 22:20:54 +0100 (IST) Received: from [10.20.78.220] (10.20.78.220) by hhmail02.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.266.1; Thu, 14 Apr 2016 22:20:58 +0100 Date: Thu, 14 Apr 2016 21:21:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: Orgad Shaneh , Luis Machado , Subject: Re: PR13984 - gdb stops controlling a thread after "Remote 'g' packet reply is too long: ..." error message In-Reply-To: <570EC0C0.8030500@redhat.com> Message-ID: References: <570C14D4.3030600@codesourcery.com> <570CFA04.3070109@codesourcery.com> <570E99DC.8080902@codesourcery.com> <570EABAA.50908@redhat.com> <570EC0C0.8030500@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-04/txt/msg00338.txt.bz2 On Wed, 13 Apr 2016, Pedro Alves wrote: > 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. I agree this is the reason of the failure. > 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. Nope, the culprit is here: /* Record the maximum possible size of the g packet - it may turn out to be smaller. */ rsa->sizeof_g_packet = map_regcache_remote_table (gdbarch, rsa->regs); and then in `map_regcache_remote_table': for (regnum = 0; regnum < gdbarch_num_regs (gdbarch); regnum++) -- so for a non-described Linux target `sizeof_g_packet' is initially capped at (79 * 8) and cannot be grown to (90 * 8) as the first `g' reply is seen, because growing is not allowed in the remote target. So it's: commit 1faeff088bbbd037d7769d214378b4faf805fa2e Author: Maciej W. Rozycki Date: Thu Mar 1 22:19:48 2012 +0000 which needs fixing, as you've correctly identified in a later reply. I think I know what to do there and I'll post a proposed fix shortly. NB this is not related to PR gdb/13984 as that bug report is about the x86-64 target. Maciej