From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id 536973858D28 for ; Tue, 1 Aug 2023 20:06:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 536973858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-ot1-x32c.google.com with SMTP id 46e09a7af769-6b9defb36a2so5536309a34.2 for ; Tue, 01 Aug 2023 13:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1690920395; x=1691525195; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=oRIL09E0Y7KzqtrcT7i4eLxnEMAfg4ealebl5kDrUWw=; b=hzvuA3LYDsCVW31OH1DlrQIVhewm8Sg/yEM14nQryvGK77HbNPJ9UcchK3c4OZhG+E stSbKZmfTAVmeg3mReDiFWx4K0xSl8MULDx4U9obOxJphDxGRV2bRavCPNEIoTzpIC0f Eyfoy5J688JxXfoXH3CWm8XJ51yfpr8bJ6OTQ6MJPwHxJUOF2LkE9eeXWBOoVzIK2ffY eLDFVuo19tx8EL/EkgVsD1gMPTNjrymYSVzHGqKMhi6xCaeP7ve4xi5NtdTfYJb6gL+a GjbgS24PD4mwzngKkKha1ak7LYFA+SqPFfqDKEDKBdJq3EG8MC0uVzBP82+PitvDY7Bj zuhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690920395; x=1691525195; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oRIL09E0Y7KzqtrcT7i4eLxnEMAfg4ealebl5kDrUWw=; b=MFMi0dzxltzYYMxBuz4uCz1o5tzPPEh1rHh3/5RQqkoTtq4JmJaqQOlHkAfwmFClkK 4MX8EzfUomUE6ElsQNeYTFC4B6QmWGuuNkuKI9epmKYD4DBXG6VaHc7ke7jcCpP7bxSA 4g+tcbQFMkJebZzcfn9hvWHQlX7xZpCsIXYa4irfocGW1L4c53dXxLSP0IGrHnLwiluN KdLzVDir837ewVknbcmJlP7Y7ELRSSPHAUEOEQzzHsVzZirKahWZ0XBBw/+rrsyzSQha Y80k75O6EZYpzmfwQFcMlDrGPX6VUDXg/sAnFxvsd6Tuk8gi1mKBsI+6txlo/NahsBVg 3GEQ== X-Gm-Message-State: ABy/qLazPyxKzvjr8iUKAXXDp4op+uR0NB0O4jQOshkDiV4xC1Fpf4Sc KKgBvdDqBiDvG5AK/jAg0gadHC0cTYjsZt5hzrJYdg== X-Google-Smtp-Source: APBJJlErqPi7OmZA2LDyUlLBgV7TXBshx4IkevSEb3yMpLPJY5L9qR8Enper6EJphlSk/SYMLzzzCw== X-Received: by 2002:a05:6870:c896:b0:1a6:4c71:8dd with SMTP id er22-20020a056870c89600b001a64c7108ddmr15735637oab.37.1690920395633; Tue, 01 Aug 2023 13:06:35 -0700 (PDT) Received: from localhost.localdomain (75-166-135-140.hlrn.qwest.net. [75.166.135.140]) by smtp.gmail.com with ESMTPSA id s15-20020a02ad0f000000b0042b2f8024c9sm3941996jan.149.2023.08.01.13.06.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Aug 2023 13:06:35 -0700 (PDT) From: Tom Tromey To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: [PATCH] Use frame.name() in FrameDecorator Date: Tue, 1 Aug 2023 14:06:27 -0600 Message-Id: <20230801200627.2901739-1-tromey@adacore.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: A co-worker pointed out that gdb's DAP implementation might return an integer for the name of a stack frame, like: {"id": 1, "name": 93824992310799, ...} This can be seen currently in the logs of the bt-nodebug.exp test case. What is happening is that FrameDecorator falls back on returning the PC when the frame's function symbol cannot be found, relying on the gdb core to look up the minsym and print its name. This can actually yield the wrong answer sometimes, because it falls into the get_frame_pc / get_frame_address_in_block problem -- if the frame is at a call to a noreturn function, the PC in this case might appear to be in the next function in memory. For more on this, see: https://sourceware.org/bugzilla/show_bug.cgi?id=8416 and related bugs. However, there's a different approach we can take: the code here can simply use Frame.name. This handles the PC problem correctly, and gets us the information we need. --- gdb/python/lib/gdb/FrameDecorator.py | 15 ++++----------- gdb/testsuite/gdb.dap/bt-nodebug.exp | 9 ++++++++- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/gdb/python/lib/gdb/FrameDecorator.py b/gdb/python/lib/gdb/FrameDecorator.py index aa9a2201bec..39ee2e2547c 100644 --- a/gdb/python/lib/gdb/FrameDecorator.py +++ b/gdb/python/lib/gdb/FrameDecorator.py @@ -75,17 +75,10 @@ class _FrameDecoratorBase(object): elif frame.type() == gdb.SIGTRAMP_FRAME: return "" - func = frame.function() - - # If we cannot determine the function name, return the - # address. If GDB detects an integer value from this function - # it will attempt to find the function name from minimal - # symbols via its own internal functions. - if func is None: - pc = frame.pc() - return pc - - return str(func) + func = frame.name() + if not isinstance(func, str): + func = "???" + return func def address(self): """Return the address of the frame's pc""" diff --git a/gdb/testsuite/gdb.dap/bt-nodebug.exp b/gdb/testsuite/gdb.dap/bt-nodebug.exp index e4dcef35a67..e9726d2e17d 100644 --- a/gdb/testsuite/gdb.dap/bt-nodebug.exp +++ b/gdb/testsuite/gdb.dap/bt-nodebug.exp @@ -44,6 +44,13 @@ lassign [dap_wait_for_event_and_check "stopped at function breakpoint" stopped \ "body hitBreakpointIds" $fn_bpno] unused objs # The bug was that this request would fail. -dap_check_request_and_response "backtrace" stackTrace {o threadId [i 1]} +set obj [dap_check_request_and_response "backtrace" \ + stackTrace {o threadId [i 1]}] +set frames [dict get [lindex $obj 0] body stackFrames] + +gdb_assert {[llength $frames] == 3} "three frames" + +gdb_assert {[dict get [lindex $frames 1] name] == "no_debug_info"} \ + "name of no-debug frame" dap_shutdown -- 2.40.1