From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id AE475393A406 for ; Mon, 3 May 2021 14:35:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AE475393A406 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 143EZrNM031960 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 May 2021 10:35:58 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 143EZrNM031960 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 0D3E81E01F; Mon, 3 May 2021 10:35:52 -0400 (EDT) Subject: Re: GDB - hardware server To: Mahesh Bodapati Cc: gdb@sourceware.org References: <0b855daa-7659-7270-ffd3-0b86498008f4@polymtl.ca> From: Simon Marchi Message-ID: <872a3a10-1cf3-4ec8-560a-e5a20f6addc4@polymtl.ca> Date: Mon, 3 May 2021 10:35:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 3 May 2021 14:35:53 +0000 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 14:36:01 -0000 On 2021-05-03 2:19 a.m., Mahesh Bodapati wrote: > Thank You. > It looks like I didn't frame my problem correctly. > server is sending the target descriptions but I have the problem when there is a mismatch between the "expected number of bytes" and "got number of bytes" > for instance, > gdb has been built for 32 bit abi by default then > case 1: > if server send 32 bit target description then we didn't see any error > > case 2 : > if server send 64 bit target descriptions then it results an error saying mismatch between "expected number of bytes" and "got number of bytes" Does this "wrong number of bytes" happens when parsing a g packet (read registers packet)? This is typically what I've seen. When you return a target description, that describes all the registers that are going to be included in the g packets. So if GDB is saying this, I would first verify that the registers you return in the g packet really match what you are describing in the target description. After connecting to your target, you could use some GDB commands to determine what GDB expects the expected layout of the g register to be. >From memory, I think this is "maintenance print registers". You can also use "maintenance print xml-tdesc" to make GDB print in XML what it thinks the target description for the current inferior is. > and my question is "how can we support 2nd case ? " > can we switch the ABI when we receive 64 bit target description from server ? if yes, how can we do that? > or do we need to build a different gdb for 64 bit ABI? No, in theory it's all supposed to work, as long as you've included the support for all the architectures you're going to use in the GDB builds. I didn't work a lot on target descriptions, so there may be some other important details I'm not aware of. Simon