From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id z9QzDh3ga2IkTgMAWB0awg (envelope-from ) for ; Fri, 29 Apr 2022 08:54:53 -0400 Received: by simark.ca (Postfix, from userid 112) id 2E3671E058; Fri, 29 Apr 2022 08:54:53 -0400 (EDT) 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=ICAysrfy; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 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 5453B1E00E for ; Fri, 29 Apr 2022 08:54:52 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 01B0E3949F1F for ; Fri, 29 Apr 2022 12:54:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 01B0E3949F1F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1651236892; bh=5nnVvokgHzAKjrE7lBax8IifYZv3b3OglDOsSEXV5Pw=; 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=ICAysrfy8GR4Yk4IlxLorqvNrtHCkVnWRCVxo+XlwjsabsbA8azKw4AeEjwcesmE+ ge71oVuEOCuKFXn4jxiUlnCDvPISj8x9WLpkpT5GrWowWmf7PwDm3pBYWdmoV7fZN9 Yp3uvhqfQ/1/RK1T2NjlFAqKl3YGXeGooPmLfLTI= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 34F73394800C for ; Fri, 29 Apr 2022 12:54:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34F73394800C Received: from [172.16.0.95] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id CC9241E00E; Fri, 29 Apr 2022 08:54:25 -0400 (EDT) Message-ID: Date: Fri, 29 Apr 2022 08:54:25 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: Hand-written assembly and Python API Content-Language: tl To: Jan Vrany , GDB mailing list References: <5dce3fb2110facb58974d1ee546c43b6db20b6f4.camel@vrany.io> In-Reply-To: <5dce3fb2110facb58974d1ee546c43b6db20b6f4.camel@vrany.io> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2022-04-29 08:32, Jan Vrany via Gdb wrote: > Hi folks, > > I'm trying to debug a code that uses a handful of > hand-written assembly routines. For example, one of > them looks like (its RISC-V but that does not matter): > > .text > .globl returnFromJIT1 > .type returnFromJIT1,function > .align 2 > returnFromJIT1: > .cfi_startproc > sd a0,248(s10) > sd s11,32(s10) > li a0, 17 > li a1, 1 > j cInterpreterFromJIT > .cfi_endproc > .size returnFromJIT1, .-returnFromJIT1 > > .text > .globl ... > > GDB clealy knows "something" about the assembly routines, it shows > the source properly and 'info symbol' works too: > > (gdb) info symbol 0x3ff75eca24 > returnFromJIT1 in section .text of /opt/riscv/sysroot/tmp/jdk/lib/default/libj9jit29.so > > The problem is how to figure out I'm in (say) `returnFromJIT1` routine > using Python API: > > (gdb) py print(gdb.block_for_pc(0x3ff75eca24).function) > None > > The only way I can think of is to parse value of `gdb.format_address()`: > > (gdb) py print(gdb.format_address(0x3ff75eca24)) > 0x3ff75eca24 > > which is bit awkward (but doable!). > > Question is: is there a better way? I can modify the assembly source > too if there's some directive that may help GDB (.cfi_startproc / .cfi_endproc > is clearly not enough). Or do I have to roll up sleeves and implement python > API for minimal symbols? I was going to say "returnFromJIT1" is a minimal symbol, but you clearly know that already. There is DWARF debug info for assembly when building with -g (at least when building with gcc / gas), but it only contains line statements, which allows GDB to show where you are in the source file (instead of showing disassembly). You won't be able to look up a block from that. I don't know of a way to do it with the current API, unfortunately. Simon