From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 543E13858418; Mon, 21 Feb 2022 09:43:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 543E13858418 From: "dominik.b.czarnota+bugzilla at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/28913] New: GDB does not initialize amd64 linux abi when orig_rax register was not provided in target.xml by gdbstub Date: Mon, 21 Feb 2022 09:43:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dominik.b.czarnota+bugzilla at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2022 09:43:29 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28913 Bug ID: 28913 Summary: GDB does not initialize amd64 linux abi when orig_rax register was not provided in target.xml by gdbstub Product: gdb Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdb Assignee: unassigned at sourceware dot org Reporter: dominik.b.czarnota+bugzilla at gmail dot com Target Milestone: --- Hello, I am implementing support for `info proc mappings` into QEMU user-mode emulation for which I sent a patch in [0]. While this patch makes `info proc mappings` available when debugging targets exposed via qemu-user, this does= not work on amd64 targets where we simply get: ``` (gdb) info proc mappings Not supported on this target. ``` This happens because QEMU does not send the "org.gnu.gdb.i386.linux" featur= e or the "orig_rax" register in the target.xml XML which it sends to GDB. However, it seems to me that those should not be required for things like `= info proc mappings` to work as a one-line change in GDB fixes this issue but the question is if it is an appropriate fix. The problem boils down to the amd64_linux_init_abi function which is called when initializing amd64 targets:=20 ``` static void amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch) { // (...) feature =3D tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux"); if (feature =3D=3D NULL) return; valid_p =3D tdesc_numbered_register (feature, tdesc_data, AMD64_LINUX_ORIG_RAX_REGNUM, "orig_rax"); if (!valid_p) return; amd64_linux_init_abi_common (info, gdbarch, 2); ``` Here, if the "org.gnu.gdb.i386.linux" feature or the "orig_rax" register are missing from the provided target.xml, the GDB returns early from this funct= ion and does not call the amd64_linux_init_abi_common function. If it called the amd64_linux_init_abi_common function, it would perform the linux_init_abi initialization [2]: ``` static void amd64_linux_init_abi_common(struct gdbarch_info info, struct gdbarch *gdbar= ch, int num_disp_step_buffers) { i386_gdbarch_tdep *tdep =3D (i386_gdbarch_tdep *) gdbarch_tdep (gdbarch); linux_init_abi (info, gdbarch, num_disp_step_buffers); ``` Which would then perform the appropriate initialization of the `info proc mappings` handler via the call to set_gdbarch_info_proc [3]: ``` void linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch, int num_disp_step_buffers) { // (...) set_gdbarch_info_proc (gdbarch, linux_info_proc); ``` I have tried to change the amd64_linux_init_abi function locally by moving = the amd64_linux_init_abi_common call before the feature/orig_rax check. When I = did it, the `info proc mappings` worked with my QEMU patch ([0]) but as I said before, the question is such fix is sufficient and does not break anything else. I would appreciate if anyone more familiar with this code could look at this and tell me if such patch would be merged to GDB or if the fix needs to be applied on the target.xml part of QEMU. Of course I have tried to extend the target.xml on QEMU side first, but this isn't as simple as adding the featu= re and orig_rax register to the XML (it seems that some additional code would = need to be added to QEMU to add support for tracking and sending the orig_rax register). [0] https://lists.gnu.org/archive/html/qemu-devel/2022-02/msg04418.html [1] https://github.com/bminor/binutils-gdb/blob/dc5483c989f29fc9c7934965071ae1b= b80cff902/gdb/amd64-linux-tdep.c#L1863-L1873 [2] https://github.com/bminor/binutils-gdb/blob/dc5483c989f29fc9c7934965071ae1b= b80cff902/gdb/amd64-linux-tdep.c#L1793 [3] https://github.com/bminor/binutils-gdb/blob/dc5483c989f29fc9c7934965071ae1b= b80cff902/gdb/linux-tdep.c#L2654-L2673 --=20 You are receiving this mail because: You are on the CC list for the bug.=