From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id i1SKJ2EuVmUR1wcAWB0awg (envelope-from ) for ; Thu, 16 Nov 2023 09:59:45 -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=dJikV6je; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 960921E0D2; Thu, 16 Nov 2023 09:59:45 -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 799191E091 for ; Thu, 16 Nov 2023 09:59:43 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 000AD3858C29 for ; Thu, 16 Nov 2023 14:59:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 000AD3858C29 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1700146783; bh=iJ+6IBaHZ+aRXCXql29DlqNunmVix3Y409j9XYiToUc=; h=To:Cc:Subject:In-Reply-To:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=dJikV6je5SV3Q1ow2ZEiXcDAYZISH2FbGKw+b06pI7MtwwwX+/Os/eZ8vXgkh/TdQ hn1pZeO6LopEz1RJ6ml68Waz5l5qc5Q3vx+AubMfBbhnbKe9f2HZuQo8FfqJBc3Kc/ 4Z5v3WZxMy61UKTzSx3//UUdmpWcC15kA9AGHK/I= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id AAFD33858D33 for ; Thu, 16 Nov 2023 14:59:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AAFD33858D33 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AAFD33858D33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700146757; cv=none; b=jiB9aisPMgjI5wpx2RQV8DGaH2nj5ABUrn0Mm7FPGn49hEBSIgC1C5ZmIrnA5OHzZwf3HMaUzeCCbm3o9qodEV+WLn8RGPFZqMVJpKE6jh2NxwTY2JvOWUgl5W+R9M0m7KbuhIQmoZBCICyJtgwO/McKfaV0v4PwF5yiu2dV5XE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700146757; c=relaxed/simple; bh=18ZMhgvMILUsDsl/zbbfw/T9kWPjqc2StRVN3v1+l1Q=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=XC2k6nR8YuNfZ1CXiIa1UrI3PORtL6o0p69um30L4MV5C0HBq0db7ScxSe0rywzLhN1FMWD6qu6T/EK4BmGbQNOvl8iuaurZ7xof5S5WJ8hfTDdS5BW8PDDLMUZikGxYUMOoGB9LQIq+cDdDbrSobzPg+6pPoSvhuSUSl+3HSbE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r3dpn-0000yq-Jb for gdb@gnu.org; Thu, 16 Nov 2023 09:59:15 -0500 Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-32f7bd27c2aso724833f8f.2 for ; Thu, 16 Nov 2023 06:59:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700146748; x=1700751548; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=iJ+6IBaHZ+aRXCXql29DlqNunmVix3Y409j9XYiToUc=; b=Ts3NpJyWa6RnSssMerFq4v6JYmQcFCHtFvI4toQIa9AAtyYAvGF8Z5vHOSdtP+fO9E eQNpO1L9HGHQb3rCLvXrAghcTslgLM4xXVC3hUnYTcTzFON8jSszLVcBczLDHJyfuHdR W00YQQxuDfPVHZ1MrxbB1cIkqmmgGa/NG7wwoXzGSQr6o5SJ4mOhvUou/xPrKwpwz2tS HexNyIrjAQKhl4d5M24GZP1RtKWx4PoD1QAl9OzuhiddRFBmg7oQzgkxxcsTVbkn4RMu IaU/Twa9Palmi/EjRzbXwinAtM38FTgs6Unxg5+/lcvgaN2msnqQ6cJN/nmeRnqKpAyM Wthw== X-Gm-Message-State: AOJu0YxwBddSjdmpOnyJkRohKge9NKqFInHpJmUE0SGyQTphaWR4Xk6+ l9jTq417j8gJ/OvDxm6S41ZEHw== X-Google-Smtp-Source: AGHT+IFWbOZ67L3fHsZaX2h3woDC9+QsHBmham4z5NPbBIo9ksTlgro5keK47KxekkUr33OpuDiGeQ== X-Received: by 2002:a05:6000:178b:b0:32f:8a08:3617 with SMTP id e11-20020a056000178b00b0032f8a083617mr12485762wrg.5.1700146747888; Thu, 16 Nov 2023 06:59:07 -0800 (PST) Received: from draig.lan ([85.9.250.243]) by smtp.gmail.com with ESMTPSA id dk14-20020a0560000b4e00b0032179c4a46dsm13943734wrb.100.2023.11.16.06.59.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Nov 2023 06:59:07 -0800 (PST) Received: from draig (localhost [IPv6:::1]) by draig.lan (Postfix) with ESMTP id 206D35F781; Thu, 16 Nov 2023 14:59:07 +0000 (GMT) To: Luis Machado Cc: Nicholas Piggin , qemu-devel@nongnu.org, Akihiko Odaki , Luis Machado , Ilya Leoshkevich , qemu-s390x@nongnu.org, Daniel Henrique Barboza , qemu-ppc@nongnu.org, Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , =?utf-8?Q?C=C3=A9dri?= =?utf-8?Q?c?= Le Goater , Richard Henderson , David Hildenbrand , "gdb@gnu.org" Subject: Re: [PULL 06/23] tests/tcg: add an explicit gdbstub register tester In-Reply-To: <37df0557-faf0-4667-925f-fcc7deac4f52@arm.com> (Luis Machado's message of "Thu, 16 Nov 2023 09:56:40 +0000") References: <20231107142354.3151266-1-alex.bennee@linaro.org> <20231107142354.3151266-7-alex.bennee@linaro.org> <87il62vip5.fsf@draig.linaro.org> <37df0557-faf0-4667-925f-fcc7deac4f52@arm.com> User-Agent: mu4e 1.11.24; emacs 29.1 Date: Thu, 16 Nov 2023 14:59:07 +0000 Message-ID: <87y1exu4lg.fsf@draig.linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=alex.bennee@linaro.org; helo=mail-wr1-x42f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_SOFTFAIL, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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: =?utf-8?q?Alex_Benn=C3=A9e_via_Gdb?= Reply-To: =?utf-8?Q?Alex_Benn=C3=A9e?= Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" Luis Machado writes: > On 11/15/23 20:56, Alex Benn=C3=A9e via Gdb wrote: >> "Nicholas Piggin" writes: >> >>> On Wed Nov 8, 2023 at 12:23 AM AEST, Alex Benn=C3=A9e wrote: >>>> We already do a couple of "info registers" for specific tests but this >>>> is a more comprehensive multiarch test. It also has some output >>>> helpful for debugging the gdbstub by showing which XML features are >>>> advertised and what the underlying register numbers are. >>>> >>>> My initial motivation was to see if there are any duplicate register >>>> names exposed via the gdbstub while I was reviewing the proposed >>>> register interface for TCG plugins. >>>> >>>> Mismatches between the xml and remote-desc are reported for debugging >>>> but do not fail the test. >>>> >>>> We also skip the tests for the following arches for now until we can >>>> investigate and fix any issues: >>>> >>>> - s390x (fails to read v0l->v15l, not seen in remote-registers) >>>> - ppc64 (fails to read vs0h->vs31h, not seen in remote-registers) >>> >>> binutils-gdb.git/gdb/rs6000-tdep.c has: >>> >>> static const char * >>> rs6000_register_name (struct gdbarch *gdbarch, int regno) >>> { >>> ppc_gdbarch_tdep *tdep =3D (ppc_gdbarch_tdep *) gdbarch_tdep (gdbarch= ); >>> >>> /* The upper half "registers" have names in the XML description, >>> but we present only the low GPRs and the full 64-bit registers >>> to the user. */ >>> if (tdep->ppc_ev0_upper_regnum >=3D 0 >>> && tdep->ppc_ev0_upper_regnum <=3D regno >>> && regno < tdep->ppc_ev0_upper_regnum + ppc_num_gprs) >>> return ""; >>> >>> /* Hide the upper halves of the vs0~vs31 registers. */ >>> if (tdep->ppc_vsr0_regnum >=3D 0 >>> && tdep->ppc_vsr0_upper_regnum <=3D regno >>> && regno < tdep->ppc_vsr0_upper_regnum + ppc_num_gprs) >>> return ""; >>> >>> (s390 looks similar for V0-V15 lower). >>> >>> I guess it is because the upper half is not a real register but an >>> extension of an existing FP register to make a vector register. I >>> just don't know how that should be resolved with QEMU. >>> >>> Should we put an exception in the test case for these? Or is there >>> something we should be doing differently with the XML regs? >> >> Yeah I suspect this is just inconsistency between targets on gdb. My >> naive assumption was XML should match the displayed registers but it >> seems there is additional filtering going on. >> >> It seems in this case the registers are still there and have regnums (so >> I assume the stub could be asked for them) but the names have been >> squashed. I guess we could detect that and accept it? >> >>> >>> i386 gdb does similar: >>> >>> static const char * >>> i386_register_name (struct gdbarch *gdbarch, int regnum) >>> { >>> /* Hide the upper YMM registers. */ >>> if (i386_ymmh_regnum_p (gdbarch, regnum)) >>> return ""; >>> >>> /* Hide the upper YMM16-31 registers. */ >>> if (i386_ymmh_avx512_regnum_p (gdbarch, regnum)) >>> return ""; >>> >>> /* Hide the upper ZMM registers. */ >>> if (i386_zmmh_regnum_p (gdbarch, regnum)) >>> return ""; >>> >>> return tdesc_register_name (gdbarch, regnum); >>> } >>> >>> So, I'm not sure how they don't fail this test. Does QEMU just >>> not have YMM/ZMM in XML regmap? >> >> No I think we only send the core one with XMM regs and there are no >> additional registers sent via gdb_register_coprocessor. >> >>> >>> Thanks, >>> Nick > > FTR, luis.machado@linaro.org doesn't exist anymore. > > As for the XML, it serves as an architecture hint/description of what fea= tures and registers > are available. > > GDB will process that and will potentially include additional pseudo-regi= sters (so QEMU doesn't > need to do so, unless it is some pseudo-register not accounted by gdb). > > The rest of the features/registers gdb doesn't care about, it will just a= dd them to the end of the > list, and will assign whatever number is next. GDB will be able to read/w= rite them, but nothing more > than that. So with a bit of fiddling I can do: modified tests/tcg/multiarch/gdbstub/registers.py @@ -44,7 +44,6 @@ def fetch_xml_regmap(): =20 total_regs =3D 0 reg_map =3D {} - frame =3D gdb.selected_frame() =20 tree =3D ET.fromstring(xml) for f in tree.findall("feature"): @@ -61,12 +60,8 @@ def fetch_xml_regmap(): for r in regs: name =3D r.attrib["name"] regnum =3D int(r.attrib["regnum"]) - try: - value =3D frame.read_register(name) - except ValueError: - report(False, f"failed to read reg: {name}") =20 - entry =3D { "name": name, "initial": value, "regnum": regnum } + entry =3D { "name": name, "regnum": regnum } =20 if name in reg_map: report(False, f"duplicate register {entry} vs {reg_map[nam= e]}") @@ -80,6 +75,15 @@ def fetch_xml_regmap(): =20 return reg_map =20 +def get_register_by_regnum(reg_map, regnum): + """ + Helper to find a register from the map via its XML regnum + """ + for regname, entry in reg_map.items(): + if entry['regnum'] =3D=3D regnum: + return entry + return None + def crosscheck_remote_xml(reg_map): """ Cross-check the list of remote-registers with the XML info. @@ -90,6 +94,7 @@ def crosscheck_remote_xml(reg_map): =20 total_regs =3D len(reg_map.keys()) total_r_regs =3D 0 + total_r_elided_regs =3D 0 =20 for r in r_regs: fields =3D r.split() @@ -100,6 +105,15 @@ def crosscheck_remote_xml(reg_map): r_name =3D fields[0] r_regnum =3D int(fields[6]) =20 + # Some registers are "hidden" so don't have a name + # although they still should have a register number + if r_name =3D=3D "''": + total_r_elided_regs +=3D 1 + x_reg =3D get_register_by_regnum(reg_map, r_regnum) + if x_reg is not None: + x_reg["hidden"] =3D True + continue + # check in the XML try: x_reg =3D reg_map[r_name] @@ -118,13 +132,38 @@ def crosscheck_remote_xml(reg_map): # registers on a 32 bit machine. Also print what is missing to # help with debug. if total_regs !=3D total_r_regs: - print(f"xml-tdesc has ({total_regs}) registers") - print(f"remote-registers has ({total_r_regs}) registers") + print(f"xml-tdesc has {total_regs} registers") + print(f"remote-registers has {total_r_regs} registers") + print(f"of which {total_r_elided_regs} are hidden") =20 for x_key in reg_map.keys(): x_reg =3D reg_map[x_key] - if "seen" not in x_reg: - print(f"{x_reg} wasn't seen in remote-registers") + if "hidden" in x_reg: + print(f"{x_reg} elided by gdb") + elif "seen" not in x_reg: + report(False, f"{x_reg} wasn't seen in remote-registers") + +def initial_register_read(reg_map): + """ + Do an initial read of all registers that we know gdb cares about + (so ignore the elided ones). + """ + frame =3D gdb.selected_frame() + + for e in reg_map.values(): + name =3D e["name"] + regnum =3D e["regnum"] + + try: + if "hidden" in e: + value =3D frame.read_register(regnum) + else: + value =3D frame.read_register(name) + + e["initial"] =3D value + except ValueError: + report(False, f"failed to read reg: {name}") + =20 def complete_and_diff(reg_map): """ @@ -144,18 +183,19 @@ def complete_and_diff(reg_map): changed =3D 0 =20 for e in reg_map.values(): - name =3D e["name"] - old_val =3D e["initial"] + if "hidden" not in e: + name =3D e["name"] + old_val =3D e["initial"] =20 - try: - new_val =3D frame.read_register(name) - except: - report(False, f"failed to read {name} at end of run") - continue + try: + new_val =3D frame.read_register(name) + except ValueError: + report(False, f"failed to read {name} at end of run") + continue =20 - if new_val !=3D old_val: - print(f"{name} changes from {old_val} to {new_val}") - changed +=3D 1 + if new_val !=3D old_val: + print(f"{name} changes from {old_val} to {new_val}") + changed +=3D 1 =20 # as long as something changed we can be confident its working report(changed > 0, f"{changed} registers were changed") @@ -168,6 +208,7 @@ def run_test(): =20 if reg_map is not None: crosscheck_remote_xml(reg_map) + initial_register_read(reg_map) complete_and_diff(reg_map) I'll wrap that into my next set of patches. --=20 Alex Benn=C3=A9e Virtualisation Tech Lead @ Linaro