From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ldZYBaLdJWJgfQAAWB0awg (envelope-from ) for ; Mon, 07 Mar 2022 05:25:38 -0500 Received: by simark.ca (Postfix, from userid 112) id 04E0A1F3CA; Mon, 7 Mar 2022 05:25:38 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 600BF1F0D2 for ; Mon, 7 Mar 2022 05:25:37 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9ABFC3858431 for ; Mon, 7 Mar 2022 10:25:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9ABFC3858431 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1646648736; bh=I/kuhsJnyxLeuInGI+da93uygZWhfsYFvzlOApsO5nQ=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=pQn491pCF/TVxHK6xj2EzHUKrRZpvf1Ikt+vqSR27ejW7QHFnXjmgJNNAfSjYmULR tpnfJQ2fGbTr+Ey0CCL/agZCRTlSPMHoy4kC4bLJ9A0acYNKwiedLrZ/dmO4k1xosR DzyozKe5b4ypFqBeNqoAy5WNd0/5UdEXG/z+SnX4= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 7B8E83858D35 for ; Mon, 7 Mar 2022 10:25:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7B8E83858D35 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-437-2N45WTNWPxqW5XHxYII5LQ-1; Mon, 07 Mar 2022 05:25:05 -0500 X-MC-Unique: 2N45WTNWPxqW5XHxYII5LQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3C9C21091DA0; Mon, 7 Mar 2022 10:25:04 +0000 (UTC) Received: from localhost (unknown [10.39.193.253]) by smtp.corp.redhat.com (Postfix) with ESMTP id C789223084; Mon, 7 Mar 2022 10:25:03 +0000 (UTC) Date: Thu, 3 Mar 2022 11:22:32 +0000 To: gdb@sourceware.org Subject: How to backtrace an separate stack? Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0fNpZF+k2+fElUIy" Content-Disposition: inline X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Stefan Hajnoczi via Gdb Reply-To: Stefan Hajnoczi Cc: tom@tromey.com, qemu-devel@nongnu.org, pedro@palves.net, "Dr. David Alan Gilbert" Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" --0fNpZF+k2+fElUIy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, The QEMU emulator uses coroutines with separate stacks. It can be challenging to debug coroutines that have yielded because GDB is not aware of them (no thread is currently executing them). QEMU has a GDB Python script that helps. It "creates" a stack frame for a given coroutine by temporarily setting register values and then using the "bt" command. This works on a live process under ptrace control but not for coredumps where registers can't be set. Here is the script (or see the bottom of this email for an inline copy of the relevant code): https://gitlab.com/qemu-project/qemu/-/blob/master/scripts/qemugdb/coroutine.py I hoped that "select-frame address ADDRESS" could be used instead so this would work on coredumps too. Unfortunately "select-frame" only searches stack frames that GDB is already aware of, so it cannot be used to backtrace coroutine stacks. Is there a way to backtrace a stack at an arbitrary address in GDB? Thanks, Stefan --- def get_jmpbuf_regs(jmpbuf): JB_RBX = 0 JB_RBP = 1 JB_R12 = 2 JB_R13 = 3 JB_R14 = 4 JB_R15 = 5 JB_RSP = 6 JB_PC = 7 pointer_guard = get_glibc_pointer_guard() return {'rbx': jmpbuf[JB_RBX], 'rbp': glibc_ptr_demangle(jmpbuf[JB_RBP], pointer_guard), 'rsp': glibc_ptr_demangle(jmpbuf[JB_RSP], pointer_guard), 'r12': jmpbuf[JB_R12], 'r13': jmpbuf[JB_R13], 'r14': jmpbuf[JB_R14], 'r15': jmpbuf[JB_R15], 'rip': glibc_ptr_demangle(jmpbuf[JB_PC], pointer_guard) } def bt_jmpbuf(jmpbuf): '''Backtrace a jmpbuf''' regs = get_jmpbuf_regs(jmpbuf) old = dict() # remember current stack frame and select the topmost # so that register modifications don't wreck it selected_frame = gdb.selected_frame() gdb.newest_frame().select() for i in regs: old[i] = gdb.parse_and_eval('(uint64_t)$%s' % i) for i in regs: gdb.execute('set $%s = %s' % (i, regs[i])) gdb.execute('bt') for i in regs: gdb.execute('set $%s = %s' % (i, old[i])) selected_frame.select() --0fNpZF+k2+fElUIy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmIgpPgACgkQnKSrs4Gr c8h8tAf+LNiry146W1h/E7+CBkKhBnlSnQM3dcKLQo7h2Anmx27SQviuw1Hwsp5g spjRrxm/+yYhMne5q1BIYJ9KwzWvNsiJqAxbuBImfIaiVdiCqmLFen3UGL1cQScI u7yIpAtjhXbjoihK00J6FKZL05+pXxRNr9xiMULQMUusp1e7Wlj7Q5BL+PhNdArI WiSsApoO7UgtqYVnL4WytCZgN+zjFZJxVv8cv3pnEIcTDvQ4ET10ptGXWt0Xh0xq L2NsPtnU3RRo/8MfpuXd7NbaLTFupyCcJyLwVLmD5QlXjEvKiJ8GrFrbU2Etufw5 OhS6eyAySHjtviovarRM8oS+mrZIgA== =HGXE -----END PGP SIGNATURE----- --0fNpZF+k2+fElUIy--