From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id k6RfOZGUm2WheTUAWB0awg (envelope-from ) for ; Mon, 08 Jan 2024 01:22:09 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=ru0Jttwp; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id DCBD91E0C3; Mon, 8 Jan 2024 01:22:09 -0500 (EST) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C72931E092 for ; Mon, 8 Jan 2024 01:22:07 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D7C513858412 for ; Mon, 8 Jan 2024 06:22:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D7C513858412 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1704694926; bh=O2EXDOlya2BcU2viQbTRaNNvd/QjxTMMXm1mK8mmGOw=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=ru0JttwpnB+5u8DfMmlhSVwukKgN2T13493S4ijJ2batEwv1nYyuCGyHnpuEG3Y5F DIUUp5Pq9LbN08LvuESZphYKAkD4i5+Dyeu8mOkF8JHiwlbj2ZweDIHR2anByzsBLB 1m924UXhIZRI6xOlyz9z5VG2Tk15TpqYE8nsEh0Q= Received: from mail.zytor.com (unknown [IPv6:2607:7c80:54:3::138]) by sourceware.org (Postfix) with ESMTPS id 7EA3F3858412 for ; Mon, 8 Jan 2024 06:21:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7EA3F3858412 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7EA3F3858412 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704694888; cv=none; b=C3wfkedyYgrHcBlrJHk9qRfDaUS6M6YI/2rzXuKqHAtmH669r2IFcpeYkZwGrxSxnQzxpkn2FBr4QliEN0dQSRMFASm2jVMLpqyAUnVng4Z4r32pKTL0c8HtYhmRh2o+xUeTU8N34DxkvT2aLyCRn4Wky7DmfI5jkDM0dV/+Ctc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704694888; c=relaxed/simple; bh=TGxsDEhIeJI4cieGLkVvRiButOWOddoGHKaITqlG1cg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=licqTF1kLv9LOWuczdDaX1gctho051TpTzWdqkZdl0kQdHv3MHm+FTjsF2yz4zrNPo6uYGUQU3VmjUywkwKpxvfLim2yuVms8d6mS7ZgUbl1foaLTe8oO2waNK9NPYJUShfVAKooR7bKPz+Zr+9uaJk9Szz61I9FdIW9jKBZsFg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [IPV6:2601:646:8002:4641:eb14:ad94:2806:1c1a] ([IPv6:2601:646:8002:4641:eb14:ad94:2806:1c1a]) (authenticated bits=0) by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 4086LLo21490865 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 7 Jan 2024 22:21:21 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 4086LLo21490865 Message-ID: <8588938b-b2c1-46e8-b6ba-5ad00b9e9b17@zytor.com> Date: Sun, 7 Jan 2024 22:21:16 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Questions on XML register descriptions To: Luis Machado , gdb@sourceware.org References: <8d4f8356-d7ee-4b84-ba8a-346207bed3e8@zytor.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "H. Peter Anvin via Gdb" Reply-To: "H. Peter Anvin" Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 12/29/23 05:41, Luis Machado via Gdb wrote: > > Ok, I went to check this again, as I had forgotten what gdb did. It looks like you're right. From the code comment about handling the g packet reply from the remote: > > /* If this is smaller than we guessed the 'g' packet would be, > update our records. A 'g' reply that doesn't include a register's > value implies either that the register is not available, or that > the 'p' packet must be used. */ > > So it looks like you can force gdb to fallback to the p packet by making the g reply packet of minimum size. > That's great. >> >> The compiler communicating it isn't essential here as I'm not trying to expose things that are visible to the compiler. What I want to do is to be able to use gdb to examine/access non-CPU-visible address spaces, like the physical RAM even when it is paged out, or the I/O address space. >> >> The problem becomes that the type of the pointer is lost if it is simply converted to an integer, and casting it back to a pointer causes it to be truncated back to 16 bits. > > Yeah, so this is the type of knowledge gdb must have in order to handle things correctly. Technically you could handle things correctly from the remote's side by inspecing the memory read/write packets, determining what the address space should be, what the pointer size might be and then going to fetch that information from wherever address space it belongs to. > >> >> I tried doing a Python script like this, but it ran into the above problem (plus the connection problem mentioned below): >> > > What particular error do you get, out of curiosity? > >> #!/usr/bin/python >> >> import gdb >> >> class Addrspace (gdb.Function): >>     """Convert an address or a pointer to the named address space.""" >>     def __init__ (self, name, base, mask): >>         self.name = name >>         self.mask = mask >>         self.base = base >>         arch = gdb.selected_inferior().architecture() >>         bits = 8 >>         while (mask|base) >> bits: >>             bits <<= 1 >>         self.itype = arch.integer_type(bits, False) >>         super (Addrspace, self).__init__ (name) >> >>     def invoke (self, val): >>         type = val.type >>         return ((val.cast(self.itype) & self.mask) \ >>          + self.base).cast(type) >> >> _io = Addrspace ("io", 0x01000000, 0xffff) >> The problem is that when the address is cast back to a pointer, it is truncated to the pointer size. Having thought about this some more I wonder if it is possible to create a new Type similar to a normal pointer but larger, and use that as the new type instead of val.type. -hpa