From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id z5PMI0/yjWWmIi0AWB0awg (envelope-from ) for ; Thu, 28 Dec 2023 17:10:23 -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=kvT76Z0e; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 84AFF1E0C3; Thu, 28 Dec 2023 17:10:23 -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 72D6B1E0AC for ; Thu, 28 Dec 2023 17:10:21 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EE7B43858409 for ; Thu, 28 Dec 2023 22:10:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EE7B43858409 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1703801421; bh=JPnD+Oe6vFGoeY5uGqWU9IUoISy7D52+4AZd5A+wLh8=; 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=kvT76Z0eSwl6JPMVitHdpfwg7WwSqvaF9XRTXbM5iv/WXMoHtqoBLzTqCJRP1Wp1l Jf8A0IfbDLSTh369Px8vVmXeahf5In1AwzoMOmMDaU6CT3goRKIzlu/d35R08AcbCA tlobSoUa844YLiK7UQj1ft/8vizdsjcdv/RTyNt0= Received: from mail.zytor.com (unknown [IPv6:2607:7c80:54:3::138]) by sourceware.org (Postfix) with ESMTPS id E7AB63858D28 for ; Thu, 28 Dec 2023 22:09:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E7AB63858D28 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E7AB63858D28 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703801381; cv=none; b=sqTxnCg5YTnLOPRAMM6v/w1xtSEvH9woOENh54NEGlqHd3aEkdagz9V+LjBur88l1oLEeVeCrm8mClxCI5kwXW+qK6RW1Vi5kITR2ByrtGvhWGFeWRU5ITVngKMgjQgu90eXcFATJlZ3qOjBQugs5EOzkh82tIIAwTRtsjTofWY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703801381; c=relaxed/simple; bh=iyxU5vO0iAfjyS6sEFdix2eVUsGdfics4PWmsUqbBFI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=peAKxydLDrGahrwxjRR0Rx2ui/y96zXcr7tS56P24zcMk+1YsCOpo6pDz9eYcljqgrqNE762ISwDp23R/nEF5RX6VSl8IKiNJZkrKk21UhMCLT97mnGweC+Qqi6jeE2WuLbhS//A8mFJKTO1fdpSazFCBgtFFRfoTDD4qnPTBWE= 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 3BSM9XcF1220605 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 28 Dec 2023 14:09:34 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 3BSM9XcF1220605 Message-ID: <8d4f8356-d7ee-4b84-ba8a-346207bed3e8@zytor.com> Date: Thu, 28 Dec 2023 14:09:28 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Questions on XML register descriptions Content-Language: en-US To: Luis Machado , gdb@sourceware.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_INVALID, DKIM_SIGNED, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * 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" Hi and thanks for responding! So more concrete background: the simulator is for a family of Z80 systems developed between 1978 and 1983. Z80 of course has both memory and I/O spaces, and on top of that, the later models in the series (and even the first ones with add-ons) had to do paging tricks to deal with the limitations of a 16-bit address space. This is not visible to the CPU, so sizeof(void *) == 2. On 12/27/23 03:28, Luis Machado wrote: >> >> 1. Some registers can't be written to, and some registers may affect other registers. What, if anything, is the best way to handle that? > > There isn't a single right way. You could teach gdb about those registers explicitly (not ideal) or you could make the remote just ignore or error out when gdb tries to modify such a register. > > As for side-effects (changing a register has an effect on a different register), this might be best implemented via p/P packets. With those gdb can write out one specific register and then it re-reads the rest of the registers. > > In such a case, you get the opportunity to apply the side-effects to other registers in time for sending the updated register buffer block. > > This is a bit odd with the g/G packets, as it gets confusing having to write all registers at once, and you might not know what values have changed or not. > This is of course true, but it is gdb that selects between gG and pP packet, not the remote (which is what I control.) Now, what I *can* do is to limit the return size of the g packet. If that means gdb will use pP packets to access other registers if/when requested, then that should deal with the problem. >> >> 2. How do the G/g commands interact with the XML target descriptions? Do they apply specifically to group="general", or are there other rules? > > My recollection of it is that G/g will request all of the reported XML register with non-zero sizes. If p/P is also supported, gdb will attempt to fetch things using g and write things using P. > That solves a lot of problems, although I expect that there might still be issues with the register cache... but that is a second-order problem if only a bit annoying. > I vaguely recall something about gdb not requesting some register in g, but I'm not sure if that's still a thing. So gdb doesn't specify anything about what g is supposed to return. The documentation only says "general registers", which *sounds* like group="general", but I have no real idea. The description of register groups say that "some register groups" have built-in meaning to gdb, but I cannot find anywhere *where* those groups and their associated meanings are described, except that "general", "float" and "vector" are described (but not their specific semantics), and "all" is mentioned elsewhere (the naming of which is kind of obvious.) There is an option "save-restore" in the register description; it is unclear to me how it interacts with the gG packets, but would at least can avoid the problem of gdb trying to restore registers that cannot be restored or would be ambiguous. >> >> 3. Is there any concept at all of different address spaces in gdb? Alternatively, is there any way to tell gdb that it should communicate addresses wider than the pointer type of the base architecture (which would allow a Python helper script to define a convenience API.> > > Yes, but the architecture-specific / os-specific layers need to be taught about it. Ideally the compiler would also establish a way of communicating this information to debuggers via the generated DWARF info. See DW_AT_address_class in the DWARF standard. > > Are we talking about short pointers here? Say, a 16-bit pointer in a 32-bit address space? > 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. I tried doing a Python script like this, but it ran into the above problem (plus the connection problem mentioned below): #!/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) >> 4. There doesn't seem to be a way to trigger a Python function when a connection is *established*, which is as far as I understand the point at which the XML register description is downloaded from the remote, and definitely the first point at which register values can be examined. Am I missing something obvious? >> > > The Python API is still growing. If this is needed, I'd make the case to the gdb community. Patches are always welcome. >> 5. I presume the byte codes use for the Z commands are the same as the agent bytecode in Appendix F, even though the latter specifically seems to be referring to tracepoints? > > Yes, the byte codes used for evaluating breakpoint conditions is the same as the ones used for tracepoints. The documentation could make that a bit more explict. > >> >> Many thanks, >> >>     -hpa >