From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=zytor.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7EA3F3858412 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:7c80:54:3::138 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2023121201; t=1704694882; bh=O2EXDOlya2BcU2viQbTRaNNvd/QjxTMMXm1mK8mmGOw=; h=Date:Subject:To:References:From:In-Reply-To:From; b=eHKzR0pAz8mBzVF2WGrg1puxjFV86tMvcncwqkmlKs0+1uXGNsNLMiDwa3E1Re6Ql oflW/jG5eneD+NIYar2DMvCACLFToqliPzqNrGHuCW1Ey3YDeWHWBP4pRpnG38+rHC 8DO5zMMtll2GcH2qomko2ZfaEM9+QE0wswnVZK0YyPnfVevL0Syp0ds2aH+u4qnM9F KceEkR2BFDE799zt+B+V7OugnV/2Oj7ZPln3FCpQFfrXfzNEn/zEARUN33aglPehIG /EPyzKHmNoY5NKRaIwUrMnr0qvBlRRB6HVMsV8Q8BCmgHGh9mjvJn/LRP5UwpnV1+d qJgcOpqlD5dww== 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 From: "H. Peter Anvin" 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 List-Id: 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