From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16280 invoked by alias); 24 May 2012 19:17:51 -0000 Received: (qmail 16099 invoked by uid 22791); 24 May 2012 19:17:47 -0000 X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,FROM_12LTRDOM,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_QE X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 May 2012 19:17:21 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SXdXE-0001ZW-MI from Maciej_Rozycki@mentor.com for gdb@sourceware.org; Thu, 24 May 2012 12:17:20 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 May 2012 12:16:59 -0700 Received: from [172.30.0.85] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Thu, 24 May 2012 20:17:18 +0100 Date: Thu, 24 May 2012 19:17:00 -0000 From: "Maciej W. Rozycki" To: Subject: GDB/remote: RSP `g' packet size, advice sought Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00122.txt.bz2 Hi, I've been struggling with a problem with the RSP `g' packet size, that once initialised may only be further shrunk, and never expanded back. The issue can be easily reproduced with the MIPS target using QEMU, e.g.: (gdb) target remote | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kc --semihosting --monitor null --serial null -kernel /dev/null Remote debugging using | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kc --semihosting --monitor null --serial null -kernel /dev/null 0x00100000 in ?? () (gdb) target remote | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kf --semihosting --monitor null --serial null -kernel /dev/null A program is being debugged already. Kill it? (y or n) y QEMU: Terminated via GDBstub Remote debugging using | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kf --semihosting --monitor null --serial null -kernel /dev/null Remote 'g' packet reply is too long: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000400000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000073930000000000 (gdb) This is because the 24Kc does not support the FPU and the 24Kf does, and hence the latter produces a longer `g' reply packet that includes the extra FPU state. However the remote backend has already shrunk its `g' packet buffer size when talking to the 24Kc and cannot expand it back. The only way to recover is to restart GDB from scratch that can be annoying. I have tracked down the cause to be the way the remote backend initialises the `g' packet size. It's only done in init_remote_state that is called once, when gdbarch data is initialized. The initial size is calculated based on the maximum number of registers supported by the architecture: rsa->regs = GDBARCH_OBSTACK_CALLOC (gdbarch, gdbarch_num_regs (gdbarch), struct packet_reg); rsa->sizeof_g_packet = map_regcache_remote_table (gdbarch, rsa->regs); Then this is further adjusted whenever a `g' packet reply is received in process_g_packet: if (buf_len > 2 * rsa->sizeof_g_packet) error (_("Remote 'g' packet reply is too long: %s"), rs->buf); [...] if (buf_len < 2 * rsa->sizeof_g_packet) { rsa->sizeof_g_packet = buf_len / 2; [...] -- which is as quoted the place the error message comes from. This certainly has to be fixed, but the question is why we only ever initialise sizeof_g_packet once? I agree we should shrink it according to the particular remote stub's needs as we need to get the size of the corresponding `G' packet right. However it looks to me like we should really reset sizeof_g_packet back to the initial size whenever a remote connection is terminated. Or it should really be enough to do this in remote_open_1. Is there any particular reason why we're not doing this? It seems so obvious and the assumption that any subsequent remote connections will only produce smaller `g' packets or at worst ones of the same size seems a little bit odd to me? It looks to me like remote_open_1 should simply call init_remote_state directly and then remote_close call a complement that we don't have yet that would free up structures allocated in init_remote_state. Does my understanding seem reasonable? Thanks for any feedback. Maciej