From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3C0DF3858D28; Fri, 29 Dec 2023 04:46:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3C0DF3858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1703825210; bh=34YoPh0dMj6V4OHGSb2FS88uXpNOk38prbBv2bvLQoo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=wILdD1NMBUUkfIqtjzrHrvCyCTplQMi3jnUMcFInF43H1UNeaFksuiDwyp1RdzIr2 XOmzsImzLXmYh52TUa1c1hoQqoxqAugsebAK7ENdhOB1FeUMOJi3rZ6D71v1oU/5SM pkLRNiEUgmKa7mkS5f9XeKqv2CrqfLz3KXBexBoY= From: "vapier at gentoo dot org" To: gdb-prs@sourceware.org Subject: [Bug sim/29869] sim: align sim register numbers with gdb register numbers Date: Fri, 29 Dec 2023 04:46:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: sim X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vapier at gentoo dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: vapier at gentoo dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29869 --- Comment #6 from Mike Frysinger --- (In reply to Tom Tromey from comment #5) > I don't really understand why this info isn't in the cgen model > either, but it doesn't seem to be. i don't think it makes sense for cgen to know about this. what we're talki= ng about here is a communication protocol for serializing & deserializing stat= e, and GDB defines that protocol. > Anyway I suspect a new field in _sim_cpu may be the way to go... while converting the sim to RSP completely is a pretty heavy lift, i think = we have some incremental steps we could consider * have gdb maintain the lists, and automatically convert/generate/export th= em to sim in the source tree. if there are XML files, use those. if there are enums in header files, use those. we already do this sort of thing with ne= wlib via sim/common/gennltvals.py, and we commit the result (rather than gen at build time via portable shell/etc...). i think we have/want to do this regardless. * add a parallel set of sim_{store,fetch}_register APIs that used the same encoding as RSP. > Though looking at this, we also don't know the size of registers. > gdb does, but it doesn't inform the remote of this -- the remote > is expected to know. when it comes to the sim APIs, gdb calls the sim with the size.=20 sim_fetch_register & sim_store_register both have a "length", and the sim basically treats it as "it has to match the register size requested via reg= no". sim_fetch_register also is designed such that passing in length=3D0 will re= turn the size of the requested register without writing to the buffer. so calle= rs could cheaply probe the size of all registers. --=20 You are receiving this mail because: You are on the CC list for the bug.=