From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39708 invoked by alias); 2 Oct 2017 15:15:26 -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 39496 invoked by uid 89); 2 Oct 2017 15:15:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=aiming 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 ESMTP; Mon, 02 Oct 2017 15:15:14 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BB61E90902 for ; Mon, 2 Oct 2017 15:15:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BB61E90902 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves@redhat.com Received: from cascais.lan (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4D27B841C1 for ; Mon, 2 Oct 2017 15:15:12 +0000 (UTC) From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH 0/3] Fix "Remote 'g' packet reply is too long" problems with multiple inferiors Date: Mon, 02 Oct 2017 15:15:00 -0000 Message-Id: <1506957311-30028-1-git-send-email-palves@redhat.com> X-SW-Source: 2017-10/txt/msg00021.txt.bz2 This series fixes some problems I uncovered while working on my multi-target branch [1]. Namely when debugging two inferiors (or more) against gdbserver, and the inferiors have different architectures, such as e.g., on x86_64 GNU/Linux and one inferior is 64-bit while the other is 32-bit, then GDB can get confused with the different architectures in a couple spots, resulting in instances of the infamous "Remote 'g' packet reply is too long" error. For example, with the test added in patch #3, we get: ~~~ Continuing. Remote 'g' packet reply is too long (expected 440 bytes, got 816 bytes): ad064000000000000[snip] (gdb) FAIL: gdb.multi/multi-arch.exp: inf1 event with inf2 selected: continue to hello_loop c Continuing. Truncated register 50 in remote 'g' packet (gdb) PASS: gdb.multi/multi-arch.exp: inf2 event with inf1 selected: c ~~~ The fix I was aiming for is in patch #3. The other two patches preemptively fix problems that patch #3 alone would cause. They're sorted this way to avoid introducing temporary regressions. [1] - https://github.com/palves/gdb/tree/palves/multi-target Pedro Alves (3): Redesign mock environment for gdbarch selftests Reimplement support for "maint print registers" with no running inferior yet Fix "Remote 'g' packet reply is too long" problems with multiple inferiors gdb/frame.c | 17 ------ gdb/frame.h | 8 --- gdb/gdbarch-selftests.c | 105 +++++++++++++++++++++++++++------ gdb/progspace.c | 12 ---- gdb/progspace.h | 11 ++++ gdb/regcache.c | 33 ++++++----- gdb/regcache.h | 10 ---- gdb/remote.c | 92 +++++++++++++++++++++-------- gdb/target.c | 14 ++--- gdb/target.h | 10 ++++ gdb/testsuite/gdb.multi/hangout.c | 14 +++++ gdb/testsuite/gdb.multi/hello.c | 15 ++++- gdb/testsuite/gdb.multi/multi-arch.exp | 24 ++++++++ 13 files changed, 250 insertions(+), 115 deletions(-) -- 2.5.5